> > I'm not at all convinced that a language is required in the specification (or
> > even in VRML); but I do think that some form of object manipulation interface
> > would be useful and not very difficult to spec out; IMHO this should allow an
> > external application to create objects, read/write their properties ("attributes"
> > and/or sub-objects), receive events (and hopefully property changed
> ^^^^^^^^^^^^^^
> > notifications), and destroy objects.
>
> Good point. Given a sufficiently sophisticated set of events, and "timeouts"
> that every client be required to support, much of the same functionallity could
> be achieved with less client-side support, albeit with increased network traffic.
> What concerns me, I guess, is that the latency of the Internet as it exists
> today is quite poor. Even T1 connectivity doesn't guarantee you good responce
> time, especially from a server that might be loaded. I'd like to see as much
> done client-side as possible.
>
> > Given the existance of such an interface, it's not so hard to bind any existing
> > or future language to a VRML implementation, thus avoiding the task of
> > specifing an interaction language and providing an incredibly high degree of
> > flexibility.
>
> What concerns me there is that I think a lot of more interesting things that
> could be done, might not- because the initial browsers lack the capability.
> Virtually every object I can think of, I would like to implement a behavior
> for, and the only way I can see to do that is programmatically on the client's
> side. I'd like my virtual radio to show the frequency as I tune it without
> round-trip requests. I'd like my virtual lamp to have an on-off switch that
> functions without round-trip delays, etc.
>
> I understand the argument against this -- no doubt, it does place more burden
> on the initial development of the browser, and God knows -- debating languages
> is as good a way as any to get involved in a religious war -- but *if* this
> is functionallity we eventually want, (and it may not be, I am speaking strictly
> for myself) then I think the best time to confront the issue and make the hard
> decision is early. The only way to counter the difficulty argument is to point
> out that (1) any browser is going to be fairly difficult to implement in the
> first place, so the marginal added complexity is probably not that significant,
> and (2) hopefully we can agree to leverage off of work someone else has already
> done by using freely available interpretor.
>
> --thomas
>
>
> 1 3 5 Thomas Churchill (KC5GAU) Voice: 408.433.1516
> |_|_| Software Technology Center Fax: 408.433.1448
> | | | NEC Systems Laboratory
> 2 4 R Western Division - San Jose, CA Email: tjc@syl.sj.nec.com
Sorry for all of the extra repeat text but it is all quite important in
forming the context of this discussion.
Fundamentally the situations presented are (by my reading):
1) Server-side behaviour management
Pro: clients require less work - few servers to update, many clients
Con: increased net traffic
Con: high potential latency
2) Client-side behaviour management
Pro: best possible response times
Con: hard to 'update' in the future with so many 'old' users
(backwards compatibility pains in the extreme)
Con: higher initial data tranfers - slow down in 'transitions'
(and look how some are with relatively small HTML
documents)
Perhaps it is not an all-or-nothing discussion? Clients could support
some type of 'extension' system - shared memory - dynamically-linked libraries
or other such schemes to 'add' behaviours - use a more modern concept of
software - cooperative - objects (or whatever). This still puts an overhead
of the client-side development but it is upfront. Look how many examples
of such a thing there are right now! Photoshop Plug-ins, AutoCAD ADS, OLE...
Perhaps with an 'option' for server-side handling in the case of clients
that are not yet updated - the user can choose to maintain client software
and gain speed or rely on server and suffer - this COULD kill the whole
endeavour - if it does not BEHAVE how someone would expect, their image
of the system suffers and it will not be recommended or supported and
will not grow as it should.
One should also put considerable thought into the difficulties of constructing
VRML modellers - having to MANUALLY edit files to add URL's or markups will
hurt the effort significantly - there are still VERY FEW useful HTML
editors and this makes it hard for the 'average' group to get up to speed,
someone specialized is needed who 'knows' the language.
I am simply pointing out issues that must all be addressed - the question is,
how do we advance on making choices?? Model definitions are one thing but
that cannot be settled it seems (at least not fully) until a fundamental
communications strategy is picked!! Then you see what is needed in the
language and how well it can be supported in modellers and clients!! An
alternative is to start on as many fronts as possible and see which work
out the best - most robust, best support, cleanest libraries, most portable,
etc. etc.
On that front, what are the existing potential 'client' and 'modelling'
environments like and does anyone have a starting point for 'server'
systems?? And, are we going to seperate completely from HTTP or build on
it (sort of reduces the Server-Side Behaviour-handling concept).
Personally, I cannot accept any interaction latency and I like everything
on client-side and 2 file formats - ASCII (easier translation) and BINARY
(smaller, faster to transmit, harder to support across platforms). Smart
clients that could 'add' behaviours would be nice as well.
What types of behaviours do people use in the VR world? Is there some
good summary?? I currently only use Object Activation, Object Animation,
and Activations based upon viewer's position (in areas, hitting constraints).
I am not a VR-person at the Tech level so I don't know what the 'language'
base is to describe these?
Hope this stirs some ideas and CONCRETE information that can be built upon!
-----------------------------------------------------------------------------
Rodney Hoinkes EMAIL: rodney@clr.toronto.edu
Head of Design Applications WWW-URL: http://www.clr.toronto.edu:1080/
Centre for Landscape Research AnonFTP: ftp.clr.toronto.edu
University of Toronto
-----------------------------------------------------------------------------