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

Gordon Wendt GordonWendt at gmail.com
Sat May 17 14:54:48 PDT 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robin, a 3 way handshake on both IM's and inventory offers would be
great but I'm just guessing that it would probably require a major if
not complete rewrite of the instant messaging system both on the
server and client sides which I don't see happening anytime soon.

- -G.W.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFIL1Q5qJF30JM0FpARAq0gAJ4rWJFj1UkCr7amFBFcAm6lP0eqTwCgl7FE
aBZ5hpn02V1AAW1JHAEQT/E=
=0bsr
-----END PGP SIGNATURE-----
On Sat, May 17, 2008 at 5:29 PM, Robin Cornelius <robin.cornelius at gmail.com>
wrote:

>
> 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 ;-)
>
>
>
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080517/6c4ab101/attachment-0001.htm


More information about the SLDev mailing list