Since I proposed the idea, maybe I should follow through and get some more
information. Anyone interested, please mail me with:
1) Suggested time/date (am, afternoon, or 6-7pm'ish)
2) Suggested location (city)
I'll summarize to the net. Brian mentioned sometime early next week,
which I also like.
> 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