I’m well aware of the difference
between HTML and HTTP. I should have stated “transported via HTTP”
rather than “wrapped in an HTML layer”. Thanks for pointing that
out. However, your access of a cgi script that
has a verb-oriented name (sendmoney) indicates that this is a form of RPC, not
REST. My questions were specifically in regards to REST and how transactions
will be implemented by Linden Labs using it. Thanks, Sam From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Wilson Vincent, On 7/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: 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
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. 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