[sldev] Re: Inventory Loss due to capped IM's

[Karl Stiefvater]

Robin -

these are all great ideas. i especially like the idea of having  
separate queues for IMs and object-offers - it could directly improve  
our content loss problem, which has been a high priority for us  
lately.   if there isn't already such a proposal in JIRA, you should  
create one.

K.



> Ok that makes sense.
>
> It boils back down to we really need a way in lsl/mono or whatever of
> knowing things have happened. inventory give really should generate an
> event when the inventory has arrived or been declined, this could  
> avoid
> a lot of little issues and ensure reliable delivery. This could be
> abused too but its just as easy to have an abusive bot so no real gain
> by not allowing it?
>
> Another thought, a person is probably not likely to have as many  
> object
> offers as normal IM's. Should these be counted separately? Another  
> idea
> may be increase the limit but add an anti spam limit of 25 from a  
> single
> object for instance. Could still go wrong in some cases though so  
> need a
> system to inform the task it failed.
>
> A number of times i have crashed at start up and lost all my messages,
> object offers etc, or even an slexchange purchase just because the
> instant messages are not acknowledged at all. Not a problem for group
> IM's (i mean notices but they use the improvedinstantmessage structure
> so i call them IMs) or normal IM's as they go to my email and groups I
> can just check directly. But a PITA for any objects given by a task,  
> as
> they are lost. Again i do get a email for this event, and know who  
> owns
> the object, but not everyone is subscribed by email for these  
> messages.
>
> It would be handy to require the server to ACK each IM back before it
> clears it from its queue as well so if for instance i crash very  
> early.
> Next time i'm back i get the (improved) Im's from where i left off.
>
> Best regards
>
> Robin, whos mixing isues together ;-)