Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008910opensim[GRID] Messaging Servicepublic2021-07-11 21:352021-07-11 23:06
Assigned To 
PlatformOperating SystemOperating System Version
Product Version0.9.1.0 
Target VersionFixed in Version 
Summary0008910: Max offline IMs
DescriptionMaxmimum number of offline IMs is hardcoded in OfflineIMService.cs at line 50.
It would be better to make it configurable trought robust.ini
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (1 Region per Sim)
Physics EngineubODE
Script EngineYEngine
Environment.NET / Windows64
Mono VersionNone
Attached Files

- Relationships

-  Notes
tampa (reporter)
2021-07-11 21:57

talking in like
really short
causing a bunch
of mail to go out
if you
send them offline to email

Sorry, but the likelihood that's locked away like that is probably to avoid allowing users to spam. Offline IM is held in database as well, so could flood that and the offline IM to email system, if you set one up. I also suspect this is to spec with SL in regards to how much you can send there before it tells you to stop.

If you really want to moving the limit to be read from config is rather simple code edit, copy pasta.
Kubwa (reporter)
2021-07-11 22:17
edited on: 2021-07-11 22:17

Everything in opensim is configurable, even the gravity in the physics. So why this is not?
I surely do understand your point tampa, but why not giving the users the choice?

tampa (reporter)
2021-07-11 23:06

I'm all for the freedom to configure everything, but even I can see why this might be a good idea to restrict having seen the amount of IM people send and keep sending even if the system tells them the recipient is offline. This being a direct insert into database has great potential for flooding and I don't want to imagine what it would look like if all was sent as mail as well.

I suppose the limit could be raised a bit. Equally I see offline IM as a way to send information that absolutely needs to be sent, not for just saying your hi's and how are you's to every one you know. OpenSim is a social platform, not a quasi-email for those too lazy to do the three steps for getting a gmail.

Nevermind that there are quite a few that use throwaway or random emails for their signup so any offline IM to email basically goes nowhere so it only really works as "oh by the way this happened" rather than a summoning call via mail.

If the limit was removed and made configurable to whatever you wanted it would need to be put on some throttle to prevent database flooding or even just preventing say 5000 messages be sent in a minute. That's quite a bit of additional code without a guarantee of it actually being preventative.

Giving users choices almost always ends in issues, especially if something seems arbitrary at first glance. The few things that are potentially dangerous and remain configurable have big disclaimers around them in the configs, but even those are, as is proven to be the status quo with humans, ignored entirely. Enforcing reasonable limits for dangerous things might seem restrictive, but given the average user doesn't understand the implications of a lot of settings, much less the dangerous ones, it's a case of protecting them from themselves.

It's almost a guarantee that given the nature of how some folks treat their IM box, there would be quite a bit of additional data coming, especially on larger grids and database access times are critical to OpenSim to behave properly. I easily see over 15000 offline IM mails going out each month and that's for a somewhat medium sized grid. There are likely quite a few that hit that limit that otherwise would send even more. That running away, willingly or unwillingly can incur costs, performance issues or even lockups when the database finally cannot catch up anymore.

There is also a max length per message enforced, simply due to how much data can be inside the string that holds it, one would say arbitrary. In the end setting limits and making sure they are upheld is a key part of making sure any software operates within an envelope that it can handle without issues. Total freedom or anarchy there can result in edge-cases or unhandled packet galore stacktrace goodbye. I'm all for configuring, I set all the LSL functions to have configurable limits, only to see the reasons they had them. The potential gain of a few that can then send more is far outweighed by the potential detrimental effects it could have, doesn't need to, but could and hypothetical issues in any complex software should never be taken lightly.

In short: A lot of the limits exist for reasons, not all, but quite a few and while they could be increases slightly, that always has to be weighed against potential issues.

Thankfully these things are easy to change if you really want to, but it might come back to bite.

- Issue History
Date Modified Username Field Change
2021-07-11 21:35 Kubwa New Issue
2021-07-11 21:36 Kubwa Description Updated View Revisions
2021-07-11 21:57 tampa Note Added: 0037856
2021-07-11 22:17 Kubwa Note Added: 0037857
2021-07-11 22:17 Kubwa Note Edited: 0037857 View Revisions
2021-07-11 23:06 tampa Note Added: 0037858

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker