I guess one should be careful about what one says on the net ...
> From: David Cake <davidc@cs.uwa.edu.au>
> Subject: Re: Scripts vs APIs
> To: linas@innerdoor.austin.ibm.com (Linas Vepstas)
> Date: Thu, 8 Sep 94 12:42:31 WST
>
> > I'll resist this a little bit.Personally, I would like to be in the business
> > of providing these tools, i.e. charging money for providing this. You know ...
> > food, rent, the bills ... I can gain a competitive advantage by standardizing
> > on the script, and selling the tools. I think this logic applies to a lot of
> > people on this mailing list.
>
> Hmmm.. I have very mixed feelings on what is suggested here. If you are
> suggesting that we do not want t a standard API because you can get a
> competitive advantage from having a non-standard one that is not well known,
> then I must protest.
No. That was not what I was trying to say.
Consider the analogy of word-processors. Far more people know how
to use them than know how to build them. Most people wouldn't want to
build them. You can get shareware/public domain word processors if you want.
I've never seen a word processor with an API. However, NeXT does have a
text object. So does Motif. So will Taligent. And the C langauge does have
str*() subroutines.
The point is, if we can standardize on the file format, and how to do drag&drop,
& etc. then people can develop VRML readers & writers and sell them and/or
give them away. All the usual logic applies -- the free tools don't have the
support, or have fewer features, or are buggier, are harder to use, have
poorer performance, interoperate less, whatever. And vendors can compete
based on this or lack of this.
An API, on the flip side, is pretty much defined by the source code.
Once you've got the source, that's pretty much it. There are very few
customers for an API (face it -- scattered corporations, and occasional
univerisites) and its very hard to sell ("my API is identical to his API,
but mine is better" ... yeah, right.)
And besides, even if you have an API, you STILL need a VRML.
> My understanding was that VRML was to be in much the same position
> as HTML, a standard that is completely open, with no one getting any
> advantage from anything to do with the language definition itself. Various
> people are free to create clients or servers, and free to sell them
> commerically if they want (but they compete against the free ones).
HTML is not an API.
> I guess I am confused because I can not understand what you are
> suggesting. Are you against a common API because you wish tools to be
> difficult to create, so there is less competition?
No. That was not at all what I wanted to suggest.
Good API's that withstand the test of time are hard to create.
Look at GKS, PHIGS, PHIGS+, OpenGL, Inventor. History is littered
with API's. The succesful ones are created behind closed doors,
and offered up to the world, after they are complete.
> Now, first, if you are suggesting that people who do not want to make money
> from VRML should leave now, I suspect that you are greatly confused about
> the make up of this list. I think that the comment is extremely inappropriate.
I don't beleive I said anything that deserves this sort of venom.
I've put a lot of code out into the public domain (MAY, in particular),
and I've watched standards bodies, and currently sit on one. I was merely
trying to point out the obvious.
> Another minor point - I am not familiar with OOGI, but YART is a
> ray trace system, not at all designed for interactive activity. This seems
> to be very different to what I consider VRMLs function.
OOGL is Univ of Minessota's submission as the VRML standard.
YART is one of components of GOOD. GOOD is supposed to have a real-time,
interactive renderer, I am told, and it also (is supposed to) have
manipulators reminiscent of Inventor, according to the blurbs.
I would imagine that you could use GOOD to implement a VRML reader,
and maybe even a writer.
> > BTW, the YART/GOOD API mailing list can be subscribed to be writing to
> > Yart@PrakInf.TU-Ilmenau.DE
--linas