[sldev] [RFC] Object to Object Instant Messaging Proposal

Kamilion kamilion at gmail.com
Mon May 28 12:25:59 PDT 2007


Hi all, Since the recent advent of llRegionSay, object to object
communications has gotten a little bit better, but I still see a
deficiency with objects attempting to communicate between regions, or
securely without a Say-type function.

What I am proposing is a new LSL Event and LSL Function, much the way
llHTTPRequest works.

function llIMObject(key ObjectUUID, string Message)
This function should send a IM-style inter-region message from an
object to another object. When received, it should trigger a new
event.

event instantmessage(key SenderUUID, string ObjectName, string
Message, string OriginRegion, key ObjectOwner, key ObjectCreator)
This event should receive an object to object inter-region message.
Like the http_response event, this event should be raised in all
scripts of the prim.

The object of this is to improve communication between objects in the
same or different regions.
Currently, we have llEmail which has been used for this for a long
time, the problems with this:
llEmail relies on postfix on the simulator to dispatch and receive the
message. This can be slow -- sometimes even taking minutes for an
email to traverse if either region or the grid is under load.
llEmail requires the use of llGetNextEmail to trigger the email event
by pulling the next email from the mbox/maildir, often requiring a
timer, and in order to provide near-realtime service, this timer needs
to be running between 1-10 seconds per llGetNextEmail call.
llEmail between prims requires knowing the other object's UUID already.

Alternatively, if objects are in the same region, they can use Listen
and Whisper/Say/Shout/Region, the problems with this:
Listen events require a channel to listen on; which means any other
object could intercept this if it knew which channel to listen upon.
Listen events require setup with a llListen call.
Listen events are usually quite fast unless the simulator is under
load or there is bulk traffic on the channel.
Listen events on channel 0 can generate a large number of pointless
events unless a proper filter is defined.

Pros of llIMObject:
Object to object communication is secure, no other object or agent can
intercept this.
Object to object communication is region independent.
Does not require postfix to deal with the message, saving simulator CPU time.
Does not require the use of complex filtering like Listen events,
saving simulator CPU time.
Object to object communication only requires the receiving object to
have a instantmessage event defined, no additional functions like
llGetNextEmail are required to trigger the event again, nor does a
llListen function/filter need to be set.
By including the object owner's key and object creator's key in the
event, security can be relatively insured.


Uses of this function/event:
Networked vendors using llEmail to request item delivery can be
improved and sped up drastically while using less simulator resources.
Grid communication speed is improved by simplifying a poorly utilized
& hacky way of doing things.
Objects requiring 'secure'/noninterceptable communications are much
easier to create; for instance, a gift card/discount coupon system.
HUD objects that may control other objects are simplified. For
instance, a popular plane uses a HUD to rez the plane itself and
display information about it's status, including a very interesting
attitude display using texture offsets and texture rotation to display
the orientation of the plane. One of the problems with this object is
if you lose your plane (for instance, you're unsat from it via an
attack by a third party, choose to unsit and fall, ETC) and are unable
to locate it, you must rely on the parcel it landed on to return it,
often arousing the wrath of the parcel's owner, or in the case of a
parcel that is not closely monitored, a crashed plane that may remain
there for weeks. With llIMObject, it would be trivial for the HUD to
include a function to cause the plane to llDie, no matter where it
might end up.
Plus there are many many other uses that I haven't conceived myself.


Anyway, I'm posting this here currently because I'd like to get some
comments on this from other residents and the monitoring lindens (Hi
Kelly!) before posting a complete feature request to JIRA.
I would also like to know if this is not feasible to implement and
why, or if the community would like the chance to alter the function
or event specifics. Strife, you're usually pretty on top of these, I'd
definitely like to hear your thoughts on this.

Thanks for reading!

 Cheers,
 -- Kamilion Schnook


More information about the SLDev mailing list