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

[Robin Cornelius]

Karl Stiefvater wrote:

> when an object (task) gives an agent an object, it does NOT go into
> their inventory
> until they accept the object.
> 
> the reasoning for this difference is to stop spamming objects from
> overflowing
> someone's inventory.  obviously this strategy can be defeated with the use
> of bots - but it does do SOME good.
> 

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 ;-)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080517/0dc300db/signature.pgp