HTTP & RPC-XML Service for Object-Object comms anyone?

Hi,

I don't quite have the time myself, but wondering if anyone is considering offering an external service for allowing ease in inter-object communications, for objects communicating any distance (cross sim).

The service I had in mind in one in which includes:

1. use of HTTP request to send messages
   
2. use of XML-RPC to receive responses (I'm saying this because I'm assuming HTTP can really only be used from inside SL towards the real world no?)
   
3. a LSL script(s) that effectively provide a LINK message interface for the user to
   1. (a) send a message to another object say from object A and
      
   2. (b) received the message in a different object, say object B
      
   
   
4. the service could also add value by following a DNS naming approach to allow a clients scripts to call remote objects via a DNS object name (just as is possible now via OBJDNS by Masakazu Kojima - http://w-hat.com/objdns ). So here the client would call like:
   1. all objects using this service at startup would send a message to the service to register there UUID against their DNS name
      
   2. sendMessage ("MyObject.ControlObject2", "message...";
      
   3. the service itself would resolve this to an appropriate UUID
      
   
   

Anyone interested in offering this? Anyone working on this?

Do you think it would provide a better/quicker comms layer than current with MAIL and CHAT?

(oh..got to go....let me know if I need to clarify further)

Yeah, I've considered doing this, but I don't know any web languages like PHP or Perl.

I do, however, have the SLLabs.com domain name, and the server behind it, so if anyone's interested in helping out, and giving me a hand in getting it all set up, I'm game.

I can also provide objdns-like services as well.

Naturally, all of this will be provided freely, anyone helping out would most certainly get credit as well. Track me down in world, IM, or just post here if you're interested in helping out.

Yeah. I posted in a different thread. I have a free HTTP service.

/54/4d/109620/1.html#post1059184

Yeah, I saw your post. Problem is, it's storing data on your server; I belive he's looking for something more like llHTTPRequest to signal the server to start a XML:RPC connection.

like llHTTPRequest(http://myserver.com/cgi-bin/openRPC.cgi)
which opens a XML:RPC channel to an object in SL.

Object to object communication would basically be opening a XML:RPC channel via HTTP from one object, doing the same from a different object, and bridging one's STDIN to the other's STDOUT, and vice versa, so input on object one's RPC channel goes to output on object two's RPC channel.

I'm aware of how it would/should work, but I'm at a loss on how to write the code to do it, myself.

thats right Kamilion,

I'm talking about providing scripters potentially with a very simple way to do distant-independant inter-object communications with good performance (i.e. with no LSL script delays like exists for email for example, or need for working around such delays). Basically just denote each of your objects with a DNS like name (not UUID as they change each time an object is rezzed) and send messages by just calling the provided script using the target object's DNS name.

I'm basically following the DNS name part of this concept now using OBJDNS however it would be nice to drop the underlying use of LINK/CHAT/EMAIL transport layers and just use HTTP/XML-RPC if it were performant. (still have a security question too to consider of course)

I'm got some UML diagrams on my plot if you want to have a look. Again because I don't get too much time whilst I have some of this working it's not really production ready

Gregs Plot SLURL

Cheers

PS I would have thought the fundamental comms layer should really be implemented by LL inside SL and not be left to content developers in this case

Yes.

Funny you should mention this, I have been working on building such a system for the last year or so Coincidentally, I have recently been making some major efforts on the project and actually hope to have it completed in the coming weeks.

My transport, called SLice (Second Life Integrated Communication Environment and yes, it came before the 'slice' cache hacking tool) is quite a bit more sophisticated than what you describe, but the basic message transport functionality you desire is designed in. It is implemented in a way very similar to what you describe and provides some other major functionality that will be of great use.

I haven't decided whether or not I will release this to the general public; I've been building it for my own personal use. The server side is currently written in threaded Python (no Apache/IIS needed whatsoever for the HTTP part) and uses Django for database abstraction. It's been fun because the db access portions of Django are most certainly not thread-safe but at the same time I've managed to get things atomic where they need to be atomic and everything is working as it should. There are a LOT of tricky issues involved in making a transport system like this, including guaranteeing message delivery, picking up where you left off should the server get shut down/crash/et cetera, tracking which objects have channels open, and more.

The current codebase runs under both Linux and Windows implemenations of Python 2.4 and because there are very few dependencies installing it is pretty simple.

Perhaps this is a good time to find out if there's much interest in a tool like this. Do other scripters see a value in such a transport widget?

Is this true? What prevents you from doing XMLRPC between in-world objects? Just the key exchange?

Of course given my experience of the reliability of the XMLRPC system, I don't really see how it would be any better than email, except possibly for prop delay issues.

- C

I am also developing my own inter-object communication mechanism, although Morse's sounds like he has done a lot of work that I have yet to do.

I am still pondering whether to make mine open due to the issues that offering an open mechanism raises, such as being let loose in an uncontrolled environment, as opposed to one you use yourself, where you know the limitations of what it will be used for.

My idea is for what I have been calling currently the Object Remote Contral Adaptor (ORCA) which provides not only message passing in-world, but also allows sending messages from web pages and applications to in-game objects, so for a simple example, you could be on your web site, and query the world to see who was on your parcel of land, and have the results displayed on your web page, while in game, have your announcement system simultaneously send them a nice little "Hello" or "GET OFF MY PROPERTY" That's just a silly example. I have a suit of objects in mind with more practical uses, that could all be controlled via the one interface.

I'm still in the early development stages though, so there's lots to be explored and expanded yet.

I have almost ready system for object-object communications with html, rpc and passwords. I think about releasing it to public. After reading this topic I think I'll add object-web and web-object communications. Stay tuned.

How about just keeping the server side stateless? Except for the DNS caching (i.e. users just effectively say sendMessage("gregsDomain.gameInstance3.controller" and it will get a message to your controller object in instance 3 of the game/system. i.e. server keeps track of the fact that this DNS like name maps to a specific UUID.

Its not just the concept of the protocol (mail vs HTTP) but also externalising UUID's from a users scripts so one doesn't have to deal with these. The system (in this case hosted outside SL) keeps tabs of the user object name to UUID mapping.

yetihehe + others: How were you planning to handle the following:

[1] multiple instances of a system rezzed - using the "domain" concept I mentioned in a couple of posts above? That is you need to be able to rez a game/system/object mulitple times, and it may be different people who buy it, so the messages have to stay within the game/system instance and not have a message go from purchaser1 to purchaser2's system.

[2] limited queues in SL (e.g. LINK, CHAT, XML..) - i.e. currently there is no way to really monitor or control (LL confirmed this to me). So if you ultimately want to pass lots of messages you may have an issue? Or perhaps this is just viewed as not an issue for the transport layer but the client side layer (i.e. the user's scripts who is using the transport layer)