llSendRemoteData

I want to use this function to do some internal communication between two objects in the same way that you can do it with llSay and llListen as well as llEmail and email. And I am little confused as to how this function works and the LSL Wiki page is pretty quiet on how to use this segment of code. Does anyone have an example and/or an explanation as to how the llSendRemoteData and all associating aspects work? :3

Thank you kindly,
Nezu

If the lslwiki is to be believed.... it doesn't work. I haven't tested it personally.

See:
http://lslwiki.net/lslwiki/wakka.php?wakka=llSendRemoteData
and
http://lslwiki.net/lslwiki/wakka.php?wakka=XMLRPCDiscussion

That function is part of the XML-RPC implementation, and is more-or-less a deprecated function/subsystem at this point. It also cannot be used between SL Objects.

Your options for that are HTTP, llEmail, or chat (if the objects are always in the same region).

Well, I was originally going to use the llEmail function because I was writing my own product update system but the 20 second lag thing is yucky and would've much preferred the 3 second time out from the llSendRemoteData.

But I didn't realize it had been depreciated, so I thank you for the heads up.

Well, the 20-second delay can be gotten around by using slave scripts and cycling through them, but really your best bet is using HTTP now.

I've looked at the HTTP code parts but I never really understood those either but from what I do understand is that don't you need some kind of URL host to use them? Those, I do not believe I have.

HTTP is not really suited for object to object communications. The URL is not set in stone and will change if the object was taken to inventory and rezzed again. It will change if the sim was reset. etc...

So in order to use HTTP you would have to have the object send it's URL to all needed to communicate with it. How do you do that? Well... you can use email

There is a set delay before a script can send another email. This delay is for the script sending the email. If you need to send something right away you would have to send it in another script while the previous script was waiting out it's email delay.

Well, the return reply from the update server to the product owner won't be emailing them. That can be done with llInstantMessage and llGiveInventory easily enough. So no worries there. I am just not sure I like the idea of having the script pause for 20 seconds because of the lag it may cause the product owner.

The function actually pauses the script, not the object. So if the script sending the email (and getting the pause) wasn't the main script...

With the advent of HTTP-In, or prim webservers, it is VERY well suited for object-to-object communications. The issue you describe is common to all forms of communication between objects. With llEmail, the UUID changes every time you rez it. Same problem exists with XML-RPC. No matter what, a "server" is going to need to use some kind of name resolution service, which isn't really much of a hurdle.

Well, if a sim is restarted the URL's are lost but the UUID's will stay the same.

For example:
Most vendor system here in SL use email to communicate. Whenever LL does a update to servers there is no need to go to all your vendors and set up the UUIDs once again. If you never take back the item to inventory the UUID will never change. You can't say that about object URLs.

While generally true, there are times when you will have to update the object UUID in your vendors. If you move your servers to a different sim (which you can use the attach/drop trick to get around, if it still works), then the UUID will change.

In rare cases, I have had rezzed objects change UUID as well. UUIDs are not guaranteed to stay the same, ever. Also have had servers completely go missing from a sim, requiring rezzing new ones to replace them.

Regardless, it boils down to the same problem, just a different frequency of updates. I use a name resolver even for my llEmail C/S systems.