Er, no. What I said at the beginning was that your CP proposal
<URL:http://hyperreal.com/~mpesce/www.html> and VRML are different issues
with different needs, and each should be able to exist independently of
the other even though bindings between them will make them powerful.
I said let's start with VRML, as it's easy to see a need for this, and
the existence of people surfing a web of 3-d spaces will show a need for
something like CP.
I am adamently opposed to putting any sort of networking-specific
functionality in VRML. Transport protocols and data types simply must be
orthogonal - that's as fundamental as the distinction between nouns and
verbs in a human language. ORTHOGONAL. ORTHOGONAL. VRML must of course
contain bindings - WWWInline and WWWAnchor for example, which can bind an
object to any type of URL accessed over any type of network, just as an
<A> tag binds HTML documents to each other over a network. But putting
Turing-machine-level scripting or behavioral languages in VRML just won't
work.
If HTTP is insufficient as an application layer for tossing 3-d scenes and
information around, and no others will suffice (including HTTP-NG) by all
means create a new one, VRTP or CP or whatever. I'll probably be the first
to agree that there are inherent limitations in HTTP. But don't pollute VRML
with stuff that really belongs in its own specification that can carry
VRML data *and* any other data type, 3-d graphical or not.
This is why I would not classify VRML as an "infosystem", even though
browsers (as valid HTTP or Web browsers) will be a part of an
"infosystem".
> The expression of behaviors in a heterogeneous multiparticipant networked
> environment is not esentially (or even in part) a computer graphics problem.
> VRML begins (because of its similarity to the ASCII syntax of Open Inventor)
> with its graphics problems *solved*, or mostly so. The networking problems
> are as yet untackled. Cyberspace is not about visualization; it is about
> communication. VRML was invented in order to provide a "front end" to a
> networking methodology I had developed; it's genesis is in networking.
Let's keep it a "front-end" - asking a VRML specification to include
both scene descriptions and a "networking methodology" will mean it'll just
become way too big for any standards body to accept.
Mark, I am not doing this because I don't think CP has no merit - I think
it should be absolutely tested and implemented if it provides a solution,
but to piggyback it on the VRML effort is unfair to CP and to VRML.
Orthogonally yours,
Brian