diff options
Diffstat (limited to 'docs/common/NGIW.html')
| -rw-r--r-- | docs/common/NGIW.html | 50 |
1 files changed, 50 insertions, 0 deletions
diff --git a/docs/common/NGIW.html b/docs/common/NGIW.html new file mode 100644 index 0000000..dfe6f83 --- /dev/null +++ b/docs/common/NGIW.html | |||
| @@ -0,0 +1,50 @@ | |||
| 1 | <html> | ||
| 2 | <title>NGIW</title> | ||
| 3 | <head> | ||
| 4 | </head> | ||
| 5 | <body bgcolor="black" text="white" alink="red" link="blue" vlink="purple"> | ||
| 6 | <p>See also <a href="../SledjHamr.html">SledjHamr</a></p> | ||
| 7 | <p>Random thoughts about Next Generation Immersive Web, or whatever we call it.</p> | ||
| 8 | <p>Here I want to indicate a possible design direction. The buzzword compliant summary is HTTP 1.1, REST and JSON.</p> | ||
| 9 | <p>I don't want to descend into the actual messy details here, so I will make some simplifications. I will assume a simplified world where there are only two kinds of things, boxes and textures. Boxes have a position, a rotation, a size, and a single texture. The software architecture will be simplified to two elements of software, the simulator and the client.</p> | ||
| 10 | <p>Suppose the simulator is at <a href="http://simulat.or/sim01">http://simulat.or/sim01</a> .</p> | ||
| 11 | <p>Then, per usual REST design, to ask about box 104, the client would "GET /sim01/object/b104". Similar to opening <a href="http://simulat.or/sim01/object/b104">http://simulat.or/sim01/object/b104</a> in a web browser.</p> | ||
| 12 | <p>The sample response might be</p> | ||
| 13 | <pre> { "at":1000, | ||
| 14 | "id":"b104", | ||
| 15 | "p":[1,1,1], | ||
| 16 | "r":[0,0,0,0], | ||
| 17 | "s":[0.5,0.5,0.5], | ||
| 18 | "t":"/sim01/texture/t104" } | ||
| 19 | </pre> | ||
| 20 | <p>This is a really important data structure, it is the representation that forms part of the REST acronym. Since we are talking about a simulator, it isn't really complete to say an object has a certain position. In a simulator all properties of objects are dependant on time. The "at" field encodes some time representation. Probably something like Unix time * 1000, aka the number of milliseconds since 1970 UTC. The "id" field is the name of the object. The "p" field is the position encoded as a JSON array of 3 numbers, the "r" the rotation (quaternion) encoded as a JSON array of 4 numbers, the "s" the size encoded as a JSON array of 3 numbers, and "t" is the texture.</p> | ||
| 21 | <p>Since we are talking to a web server, and since we want to sometimes reference textures from other places than the simulator, the value of the texture is a URL. In this case a relative URL that leaves out the server, thus meaning the full URL to the texture is "<a href="http://simulat.or/sim01/texture/t104">http://simulat.or/sim01/texture/t104</a>". If the client needs the texture it can do a GET of "<a href="http://simulat.or/sim01/texture/t104">http://simulat.or/sim01/texture/t104</a>". There are ways to further compress this information, but let's not fix what isn't broken.</p> | ||
| 22 | <p>Supose the user moved the box up 1 meter by some manipulation of the client. The client would "PUT /sim01/object/b104" with the data</p> | ||
| 23 | <pre> { "at":1001, | ||
| 24 | "id":"b104", | ||
| 25 | "p":[1,1,2], | ||
| 26 | "r":[0,0,0,0], | ||
| 27 | "s":[0.5,0.5,0.5], | ||
| 28 | "t":"/sim01/texture/t104" } | ||
| 29 | </pre> | ||
| 30 | <p>Always transfering the full representation of an object could be wasteful and error prone so I slightly bend REST. I will use POST to an object to transmit only the changed fields. So "POST /sim01/object/b104" with the data</p> | ||
| 31 | <pre> { "at":1001, | ||
| 32 | "id":"b104", | ||
| 33 | "p":[1,1,2] } | ||
| 34 | </pre> | ||
| 35 | <p>would cause the same change in the simulator state.</p> | ||
| 36 | <p>To get the current state of the world "GET /sim01/object" would reply with all the objects. In this case it would be a JSON array of JSON objects similar to the first example above:</p> | ||
| 37 | <pre> [ {"at":999,"id":...}, {"at":999,...} ... ] | ||
| 38 | </pre> | ||
| 39 | <p>But, look what happens when we understand that the reply is using chunked encoding. The simulator might not actually ever finish sending the state of the world. The client might get</p> | ||
| 40 | <pre> [ {"at":999,"id":...}, {"at":999,...}, | ||
| 41 | </pre> | ||
| 42 | <p>in the first chunk, and more</p> | ||
| 43 | <pre> {"at":1000,...}, {"at":1001,...}, ... | ||
| 44 | </pre> | ||
| 45 | <p>in the second chunk. And so forth. Again, sending all the fields of all the objects, even for just the changed objects is wasteful. I see a few ways to go.</p> | ||
| 46 | <p>If the server knows it has sent a full description of an object to a client, then future updates would, like the POST, only include the changed parts of the object.</p> | ||
| 47 | <p>Alternatively, lowering the load on the server, the client closes the "GET /sim01/object" connection at some point, and does "GET /sim01/object?delta". At that point only updates are ever sent. If the client sees a change to some object it doesn't recognise, is opens a second connection and requests "GET /sim01/object/b999" for example to get the full description.</p> | ||
| 48 | <p>The third alternative is that all the server ever sends in response to "GET /sim01/object" is a stream of changes. If the client doesn't have enough information to render an object, it can query the individual object as in the first example.</p> | ||
| 49 | </body> | ||
| 50 | </html> | ||