Sorry, our local system fileserver lost one of its disks and took out the
rest of the subnet with it.
< The URL seems to be broken right now.....
It was on the same network, and is working now.
< I don't understand. VESP is a binding between a a transport-layer
< protocol (HTTP-NG) and an object description language (VRML)? Why does
< there need to be a binding?
Actually, VESP doesn't do that, its goals are to create an easier means
of doing that, amoung other things (that being transporting VRML scenes).
< What does a VRML browser that uses HTTP-NG lack that your protocol specifies?
The main thing would be how a client handles HTTP-NG or whatever
protocol it is using. In order to connect to a mud / virtual environment
server, you must have an interactive screen _somewhere_, where you can see
and type your commands (basically, something equivalent to a telnet session
in an xterm, but higher level and part of the client), and the client must
be aware of what is occuring on this interactive session, so that when the
server responds to a command, the client knows what is up. Most likely the
only implementation of HTTP-NG is to transfer objects over the network,
which the user never see's. By defining specific session IDs for certain
purposes, the implication that they are treated different is already
given.
< What's the significance of the numbers, and why define numbers for
< what looks like could easily be accomplished using MIME types?
In the SCP protocol each session has a relative ID associated with it,
which is a "number". The protocol also states that IDs 0-1024 (I believe)
are reserved. Therefore I picked the first simple non-reserved integers
and started the sequence at that point (yes, it was a random thing--the
entire specificaton took less than 15 minutes to write, it is only intended
as a base to start discussion for a real protocol)
< What is the benefit of this versus just classifying the information and
< letting the server and browser work it out on their own? A server can
< definitely distinguish between what it sends and what it receives, so I
< don't see why it needs a standard SID to tell it that....
But, this is a means of classifying that information, at a lower level
than simple markup (which also makes it faster). It also allows for
multi-threaded tasks to handle things correctly. For instance, assuming
you are using a markup language of some sort which defines <object oid>,
where oid is the object id. You have two objects currently being
sent to the client (obj1 and obj2):
-------------
<object obj1>
This is text, which pertains to <object obj2>When something totally
unrelated text that has nothing to do with the other object occurs</object>
but which can be fun</object>
-------------
Where the two lines are:
-------------
This is text, which pertains to text that has nothing to do with the
other object but which can be fun
-------------
and:
-------------
When something totally unrelated occurs
-------------
Keeping a single stream clean in this instance is not easy (I've tried to
come up with various systems to handle it on the server I'm working on).
However, handling it using something such as the SCP would be easy, as
you would only be placing information relative to that stream in each
session's packet.
As far as the standard SID, that is just to give people something to
start from. People need a base--you are in no way restricted to those
SIDs, nor do you even have to use them.
< I'm very
< confused by all of this, it just seems to be in two layers at once
< (the application layer and the transport layer) when those layers should
< be as orthogonal as possible.
Actually, two layers is what is required. I've been trying to work out
some sort of stream control markup language for muds for over a year and
a half now, and my biggest problem has been in that they really shouldn't
be considered as one. Taking them as seperate entities rips out all of
the problems and creates a simple clean system.
The only reason VESP is really specified at all is to give people a base
to begin with. You cannot really just "use" HTTP-NG for this purpose (of
an interactive login) without defining some sort of base to build upon.
All VESP really truley is, is a set of guidelines for using HTTP-NG in
a Virtual Environment System.
Also, for note, my true idea of how a VES would work is that each textual
stream/session would have a content type associated with it (of course) and
that you would use html, or vhtml (specified at the site) to markup the
stream so you have more than flat text.
-Brandon Gillespie
---
the Cold Dark Virtual Environment: http://recumbent.declab.usu.edu:1180/
"They who dream by day are cognizant of many things which escape
those who dream only by night." - Edgar Allan Poe