I'm not sure of what you mean here, so I'm not sure I agree. It *sounds*
like you're putting the onus on the VRML description to handle the
binding to code. I see the flip side as being at least as promising:
having the code side bind to the VRML object.
I should make this clearer: what I mean is that the code would describe
a "conceptual" object, in the usual sense. This would, among other things,
indicate the VRML object that is part of that conceptual object -- the
VRML is basically a part of the larger object, describing the "static"
attributes of the object. The code would then go on to define the methods
for that object.
I'm not certain that this is the way to go, but it has some
advantages. In particular, it allows VRML per se to remain a
relatively pure static-description language, without touching the
dynamic side at all, allowing the dynamic stuff to be entirely
encapsulated in a language better suited to that. Whether that's an
real advantage or not, I'm not sure; I can easily see arguments either
way...
(Of course, there are lots of issues here. In particular, I'm trying
to envision what a dynamic scene layout system is going to look
like, five years down the line; these issues relate as much to ease
of design as to ease of browsing...)
>There should be a stream field specified in VRML specifying multicast
> channel or machine:port.
Heavens -- why? I don't see this at all.
>Objects must be able to query the browser to determine what interfaces (API's)
> it supports.
Not a terrible idea, especially if connected with a Java-like ability to
dynamically upload new interfaces. Needs more definition, though.
>Example of potential interface:
> Simulation:
> bind_event() //bind function to event
> trigger_event() //broadcast event to
> // browser if simulation is run local
> // server if browser is a client
> // clients if browser is a server
> // to the ether if browser is peer
> // on multicast channel
>Interfaces should be IDL files for standards sake, and to ease
> binding to OLE or CORBA compliant objects.
Maybe; heaven knows there are a number of different approaches here.
Not to get religious (I'm not deeply enough immersed in any approach
to be religious on the matter), but the Java approach is another
possibility, and *may* turn into an emerging standard.
(On the other hand, I know little about IDL, so I may not be grasping
what you're getting at here...)
In general, these sound like intriguing ideas, but need a little more
flesh (and preferably some more concrete examples) to be more easily
understood...
-- Justin
Random Quote du Jour:
"There are no Famous People on the net. Only some of us with bigger mouths
than others."
-- Da Roach