[SWMP] Use Case 1: Initialization from a URL

One of my colleagues, who is knowledgable about standards, advocates that 
a standardization team should have a clear set of use cases that drives 
their thinking.  He has also posed this as an initial use case:

"You look at an ad or a billboard and see a URL for a neat virtual world. 
You go back to your browser and enter the URL to arrive at the virtual 
world."

How do we see that happening?

Mostly to get the ball rolling, let me offer an answer to this question. 
Others are possible, but this reveals my thinking about how swmp would 
work with other protocols.

1.  I assume that the URL takes the form 
"swmp://VWServer.VWHostCompany.com/shard"
2.  I assume my browser is equipped with a plugin that knows how to deal 
with the swmp protocol scheme.
3.  The browser contacts VWServer.VWHostCompany.com using the swmp 
protocol and requests information about the shard node.
4.  The browser asks for the "X3DURL" field of the shard node to obtain 
the static description of the shard's 3D model.  This is a predefined and 
reserved field name that may only be used to hold a URL that links to an 
X3D description.  Alternatively, there might be a "ColladaURL" or any 
other exchange representation for a 3D description of the virtual world. 
In some cases, it might be sensible to split the terrain description from 
the base objects in the world.  The main point is that swmp does not 
assume responsibility for transmitting static aspects of the world.  These 
are retrieved via http.
    - In general, I would expect the static aspects of the world to be 
retrieved before subscribing to the shard via swmp.  After subscribing, 
one will learn about swmp nodes that will often bind to previously 
downloaded static nodes.  You will want these in place before the 
subscription information starts arriving.
    - I think of the relationship of a swmp node to its static node as 
like that of an instance to its class.  The static description might be 
reused in many shards, but only this instance has these dynamic settings. 
While we can assume that the dynamic representation "knows" the static 
representation that it builds off.  The reverse is not true.  We cannot go 
to the static representation to discover the dynamic shard.  In the 
general case, the static representation might support many dynamic 
instances and might not even "know" about all of them.  (Consider a 
standard office layout.  We all use it to create our personal virtual 
office, but then we customize it by adding pictures, furniture, and links 
to other rooms.)
5)  Once the static description is retrieved, we subscribe to the shard. 
This results in a stream of messages describing the dynamic nodes of the 
shard.
6)  Insofar as newly identified nodes bind to nodes downloaded via the 
X3DURL, we simply facilitate the binding of this information into a single 
object representation.  Thus, for example, the static representation of 
the shard might have included a building with a door that could be open or 
closed.  Based solely on the static description we would take the default 
setting (perhaps closed).  After receiving the dynamic information via 
swmp, we would discover that the actual setting is now open and update the 
object as needed.  The subscription will ensure that future modifications 
to the door will be noted as they occur.
7)  As we learn about the dynamic aspects of the shard, we will find that 
some swmp nodes do not correspond to already identified nodes.  These are 
nodes that have been added to the scene.  They should have their own 
"X3DURL".  We would retrieve this static description and add it into the 
model that we are building.
    - Note that the X3DURLs need not come from the same server.  This is 
important.  We will want to populate a shard with objects found in a 
different catalog.  There is no reason that the place and the stuff in the 
place must come from the same service.
    - Note that avatars are simply another object (albeit an important 
one) in the shard.  In general, I will want the service providing my 
avatar description to be separate from the service providing a world. 
That's what will permit me to go from world to world without changing 
avatars.
    - Since a swmp hierarchy might be sparser than the X3D hierarchy, it 
might be necessary to define a special field that identifies a new node's 
parent.  I'm not certain what else might be needed to ensure that new 
nodes are effectively bound into the runtime hierarchy of nodes.  If other 
information is needed, we will probably need more of those predefined and 
reserved field names.

I think that's it. 

My biggest concern has to do with whether the swmp hierarchy must be 
complete.  If it must be complete, then we may find ourselves reporting 
about a lot of nodes that do not contain any dynamic information.  If it 
is not complete, then the runtime hierarchy is entirely emergent from a 
combination of the static and dynamic information.  I am not sure this is 
a problem, but it seems precarious.

jfp