If people are really interested in a shotgun marriage, I suggest that an
explanation of just exactly what is supposed to happen in the Java/VRML
connection would be helpful. VRML beowsers are not written in Java, so just
what exactly will the Java code say to the beowser? If you expect me to
write Java code, you are going to have to tell me what my code is
supposed to say to a VRML beowser. Doesn't one set of code have to tell
another set of code to do something?
I agree that CORBA is no model, but declaring that distributed computing
must be done in C++ (or Java) would not solve the problem either. CORBA is
being knocked off by a related solution (hold your flames, please, OLE
could suck eggs for all I care) in distributed OLE and Microsoft power.
This sounds a lot like declaring victory and going home.
On Fri, 13 Oct 1995, Anthony Parisi wrote:
> Hear, hear!
>
> Paul - I couldn't have said these things better myself. Your approach to an
> OO API is what several of us have been advocating since last October's Web
> developer conserence. Why leave CORBA, OLE, TCL, Visual Basic out of the
> party?
> Also, I share your some of your concerns about Java licensing. Perhaps Sun
> can make a statement to the list to clarify their position and alleviate
> peoples' fears?
>
> >Mark Pesce <[email protected]> writes:
> >> Java has saved VRML from a CORBA-like future that would
> >> have collapsed of its own weight.
> >
> >I don't understand where this fear is coming from. How do you plan
> >to wed Java and VRML without designing an OO API? Once you have an
> >OO API, what's so frightening about expressing it in IDL and
> >thereby making it (potentially) available to multiple languages?
> >
> >I'm as big a fan of Java as anyone, and I certainly think we should
> >aggressively work to bring the two together. I even agree that
> >picking one initial "preserred" language for VRML is an excellent
> >strategic move. But I don't see the urgency -- or purpose -- of
> >permanently locking VRML into a single scripting language.
> >
> >The *hard* part of standardizing VRML 2.0 will be designing and
> >agreeing on a good OO API. All I'm asking is that the VRML 2.0
> >standard be based on the essentials -- the abstract API we come up
> >with -- and not superficialities of a concrete Java binding.
> >
> >I'd also like to point out that this is a very difserent situation
> >(and a much bigger gamble) than our earlier standardization on
> >Inventor syntax. SGI made QvLib freely available to other
> >developers, helping them implement "Inventor emulation" relatively
> >quickly. Java is a *much* more complex system, and Sun clearly does
> >not plan to give away its compiler or euntime source code to
> >commercial developers. How does your proposal not amount to
> >requiring commercial developers to shell out $100,000 or whatever
> >Sun's license fee happens to be?
> >
> >Again, I'm all for using Java as an express train to the future.
> >But let's not handcuff ourselves to the seats, or we'll miss our
> >station.
> >
> >--------------------------------------------------------------------
> >Paul Burchard <[email protected]>
> >``I'm still learning how to count backwards from infinity...''
> >--------------------------------------------------------------------
> >
> >
> __________________________________________________________________________
>
> Intervista Software
> Cyberspace Development
>
> Tony Parisi [email protected]
> President http://www.intervista.com/
> __________________________________________________________________________
>
>