NGIW.Commands

From 080e27a38c508b2370cfe7f0152183f99a17131a Mon Sep 17 00:00:00 2001 From: David Walter Seikel Date: Sat, 20 Feb 2016 12:31:37 +1000 Subject: Rearrange the docs. --- docs/common/NGIW.Commands.html | 46 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 docs/common/NGIW.Commands.html (limited to 'docs/common/NGIW.Commands.html') diff --git a/docs/common/NGIW.Commands.html b/docs/common/NGIW.Commands.html new file mode 100644 index 0000000..c058a6f --- /dev/null +++ b/docs/common/NGIW.Commands.html @@ -0,0 +1,46 @@ + +NGIW.Commands + + + +

In a virtual world there are many places where an actor (either an avatar directed by a human, an avatar directed by a program (bot), or a scripted object) wants to do something to an object. Something other than just directly change a property of the object. The LSL programming model is that scripts react to events. So I propose we unify commands, LSL events and REST by manipulating even queues.

Proposal

If http://sim.ulat.or/obj/oid is the url to some object with id oid, and we have a http connection to http://sim.ulat.or then

PUT /obj/oid/eq -- adds a new event to the queue (at the end)
PUT /obj/oid/eq/0 -- adds a new event to the queue at the beginning
PUT /obj/oid/eq/9 -- same behaviour as PUT /obj/oid/eq
GET /obj/oid/eq -- returns the full event queue
PUT /obj/oid/eq/eventid -- changes the event (or adds one) with id eventid
GET /obj/oid/eq/eventid -- returns the event with id eventid or an error
GET /obj/oid/eq/0 -- returns the first event from the queue or an error
GET /obj/oid/eq/9 -- returns the last event in the queue
DELETE /obj/oid/eq/eventid -- removes an event from the queue and returns it
DELETE /obj/oid/eq/0 -- removes the first event from the queue and returns it, or returns an error

And maybe

PUT /obj/oid/eq -- add a bunch of events to a queue
PUT /eq -- add a bunch of events to a bunch of objects?

What a PUT really sends to the server

Supose we are telling the server about the avy touching an object. The actual text that gets sent might look like:

   PUT /obj/oid/eq HTTP/1.1
+   Host: sim.ulat.or
+   Content-Type: application/json
+   Content-Length: xxxx
+   
+   {"touch_start":{"force":13,"avy":"uuid","time":1311663233}}
+

So you can see it is fairly heavy weight compared to a tuned command language. I will investigate what subsequent requests look like when using the http 1.1 persistent connection features. At the worst the http overhead can be amortised across many commands by using the last two forms of request. The last would look like:

   PUT /eq HTTP/1.1
+   Host: sim.ulat.or
+   Content-Type: application/json
+   Content-Length: xxxx
+   
+   [{command1...},{command2...},...]
+

+ + -- cgit v1.1