Please see the previous mail I just sent to Sami and copied to the list. Both of
you jumped to conclusions based on my not presenting you with a comprehensive
set of opinions, so I think you filled in the blanks with info from your
current project! I was in non way suggesting the distribution of binary-linkable
cross platform code. Feh ! This is patently ridiculous ! (I'm actually rather
amazed by the way that two members of Sun engineering jumped straight in to this
! I'm now assuming that Sun/Java has more interest in VRML than I'd previously
thought). It is entirely obvious (in my opinion) to anyone half sensible that
some form of client-side processing must exist, be it via an interpreter running
bytecodes or some form of compiler engine processing ASCII.
I do agree with your point on dynamic loading not being supported on all
platforms, however. What I was raising a flag about was the rather narrow way in
which people are thinking about langauges in general. They seem to have them
boxed into interpreted languages, compiled languages, etc, and I wanted to avoid
this kind of thinking affecting the debate we are currently having on behaviors
- ie "An interpreted language is the only way to do this". No so. Progress
currently has in-house technology which rather neatly translates what has
traditionally been an interpreted language (VB (hm !) !) into a small (read tiny
!) UI broker, and a set of (compiled) binary runtimes which are linked to the UI
broker. This technology forms the basis of one product which we expect to ship
later on this year, and could easily be modified to form the basis of a secure
client side compilation environment.
-- Mike
On Apr 17, 3:02pm, [email protected] wrote:
> Subject: Re: TGS driving VRML 2.0?
>
> > On Apr 17, 12:06pm, Dave Nadeau wrote:
> > Dave wrote :
> >
> > > 1. Dynamic loading is not supported on all architectures.
> > >
> > > 2. There are zillions of architectures, operating systems, and OS
versions.
> > > Supporting every one of these is not practical.
> > >
> > > 3. Security security security. Downloading a binary, linking it in to
> > > your application automatically, then executing it is a virus writer's
> > > dream.
> > > An interpreted language, such as Java, addresses each of these issues.
> > > It may be a hassle, but the consequences of not doing it are horrifying.
>
> [email protected] (Mike Roberts) replied:
> > Agreed, but I think we both agree that it is not the fact that the language
> > is interpreted that provides the benefit, but because the transformative
> > apsects of the language on the local system are restricted in some way ...
>
> Sami Shaio has already replied about the benefits of an interpreted system
> in achieving security, but I also wanted to point out that your generalization
> here only applies to Point #3 above (security). Points 1 and 2 (architecture
> neutrality) are also very neatly solved by using an interpreted language.
>
> ...jim