First, don't confuse HTTP and HTML.
HTML is nothing but a document format. It defines how things are stored and represented in the text stream. Actually, HTML is a form of XML. Just like web servers can send you GIF's, JPEG's, and even executable files, there's no reason that an HTTP server can't send any sort of binary data.
This is completely separate from the HTTP protcol. HTTP is the defition for how things are transmitted. When your browser requests a web page, HTTP is responsible for moving the request to the server and then moving that data back to your computer.
second, this approach is perfect for transactions like this. You simply define a command as part of the URI. It could look something like this:
http://assets.secondlife.com/sendmoney.cgi?sender=0123456789abcdef01234567890abcdef&recipient=0123456789abcdef01234567890abcdef&amount=12345
the server would then process the transaction and return an XML string that confirms the transaction, along with the new balance, and reasons for failure, if the transfer failed.
This is actually a perfect function for an HTTP interface, since it involves a finite amount of data, is a discrete transaction, and takes a relatively short amount of time.
Just like in the world of object oriented programming, where objects can have fields and properties, where properties "do things", you can have URI's that "do things". Otherwise, the web-based e-mail system I'm typing this message on wouldn't work. :-)
Thank you for the valuable information Donovan.
I have a question:
I'm not sure I see a good REST-based method of, for example, transferring money from your avatar to another person. Whereas RPC offers procedures (methods) to be called to invoke certain functionality, a true REST-based approach offers only objects with properties. How are you going to support transactions between two (or more?) avatars/objects through this system? It would seem as if a true REST-based system is nothing more than a database (without stored procedures) wrapped in an XML layer, further wrapped in an HTML layer. Is this right?
Thanks,
Sam
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Donovan Preston
Sent: Thursday, July 20, 2006 10:10 AM
To: Development list for libsecondlife
Subject: Re: [libsecondlife-dev] Hello from The Lindens
On Jul 20, 2006, at 12:31 AM, Tom Wilson wrote:
I was a little confused about what REST is, so I looked it up.
Let me see if I understand what this is all about:
REST is kind of a philosphy of network client/server design. In the real world, HTTP (the actual protocol used to transfer web pages from www servers to your web browser) is an implemenation of that.
Basically, we send a URI to the server (just like when you type in "http://www.secondlife.com ") and the server sends back a response with some XML stuff in it. That XML stuff can be data (such as an object or texture) or a status message (like "money transfer succeeded")
Yes. This is correct. REST means Representational State Transfer. Let's deconstruct that a bit. A representation is a way of encoding some data. For example, HTML, XML, _javascript_ JSON, and a screenshot (a series of binary pixels) of a rendered HTML page are all representations of some data somewhere. State is a word that programmers use to mean a condition that an object is in at a particular instant in time. Transfer refers to the act of moving a representation of state from one machine (our servers) to another (your machine, or a proxy).
That's all, really. In order to find out about the second life world, you are going to request the transfer of representations of server-side state.
Is this going to eventually completely replace the protocol that the SL viewer uses to communicate with the servers, or is this going to be a secondary protocol that we would use for data exchange with third-party applications?
No, this is not going to completely replace the UDP protocol. While expressing, fetching, and mutating state using REST is useful for some applications (for example, creating an HTML page containing a list of land for sale) it is not appropriate for real-time unreliable updates. Movement updates, object manipulation, and other operations where there is a continuous stream of updates and once the viewer's "simulation time" has passed where the event was will continue to be expressed using the existing UDP protocol (hopefully improved to be less fragile in the face of message template changes).
The other thing that I'm now curious about is whether we'd be able to interact with SL without actually showing an avatar. Sending IM's, transfering items, or looking at the various lists really are independent of the simulator. It would be nice if we could connect our third-party programs in a "sim-less" state for tasks that don't require interaction with the visible part of the SL grid.
Yes, this is one of our most important long-term goals, and is a large motivator behind moving to this architecture.
[ Forgive me if that sounded dumb or weird. It's late, so stuff is just coming out of my brain without the usual filters. :-) ]
Not at all, you brought up a number of very important points :-)
Donovan
_______________________________________________
libsecondlife-dev mailing list
libsecondlife-dev@gna.org
https://mail.gna.org/listinfo/libsecondlife-dev
--
Tom Wilson
[EMAIL PROTECTED]
KI6ABZ
_______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev
