Re: [openvrml-develop] request for comments : a perl module for openvrml

[Braden M. <br...@en...>]

On Thu, 2001-09-27 at 13:55, John Richardson wrote:
> Hello,
> 
> >OpenVRML does not presently provide a C interface; just C++. It is
> >possible to write a C wrapper around the C++ interface, but it doesn't
> >make a lot of sense to pursue that until our API has solidified more.
> >
> >Even then, providing a C interface is quite a bit of work for something
> >I'm not sure would be widely used. There are two reasons to have a C
> >interface:
> >        * to use the library from C applications.
> >        * to use the library from applications written in scripting
> >          languages that know how to talk to C libraries.
> >
> >It's my feeling that there aren't too many folks using C who want to use
> >OpenVRML. I think most of our users and prospective users using this
> >kind of a programming language are using C++.
> 
> If you were to use the library in a XCMD or XTRA on the Mac you would have
> to use C. On the Macintosh you just set the Codewarrior flag to use the C++
> compiler. Then put extern "C" in the header files. So, in  a sense it is a
> non issue, at least on the macintosh under OS 9.

'extern "C"' only makes sense for things that are C constructs, like
functions, typedefs, and POD types. Creating a C interface for OpenVRML
would involve providing function and POD-type wrappers around the
classes in the interface. The task is straightforward, but it's a lot of
work.

The good news is that after the rearchitecture, our API will be smaller
(mainly since the different classes for each individual node type will
nolonger be part of the API).

I don't know what XCMD or XTRA are.

> >As to the second point, I do think it would be very nice to be able to
> >use OpenVRML from scripting languages. However, I think most scripting
> >language users will expect a relatively high-level interface, like the
> >EAI. And that is exactly what I would ultimately like to provide. I
> >still think it is a sound plan to use CORBA for this interface. We just
> >need more infrastructure in place before active work on this becomes
> >practical.
> 
> I use the SuperTalk language to control the Mac vrml viewer. So I either
> use Apple Events which are supported by SuperTalk or I would use EAI. One
> other way would be to use an XCMD.
> 
> Note that just having stable script node and EAI and Java support is not
> enough. You need some methods that allow the viewer to access the script
> node so that GUI's can directly utilize the functionality of the script
> node and Java / EAI. It is after all, a library that would be used by
> GUI's. So where is the API for the implementation?

I think the kind of communication you're talking about falls outside the
domain of the Browser Script Interface or the EAI. These interfaces
facilitate communication between programming languages and the VRML
world. You seem to be talking about communicating between different
execution contexts. These mechanisms should be provided by the
programming language and its libraries.

> >> mostly for using to parse and validate vrml
> >>
> >> a heady task im sure
> >> &
> >> im really not sure what i need to know
> >
> >OpenVRML already parses and validates its input. What kind of
> >application are you envisioning?
> >
> 
> Well, the obvious problem is content creation tools. Some tools just pump
> out bad VRML 97 but some just pump out senseless VRML 97. I have had
> Cortona (Mac) and OpenVRML choke on exported VRML from Design Workshop
> 1.8.5 and Amapi 6.  I can also get Cortona (Mac) and Blaxxun (PC) to choke
> on Ray Dream Studio export unless touched up by Spazz3D. Amorphium 1 and
> Inspire (Lightwave lite) export usually work in Blaxxun on a PC or under
> VPC 4. The programmers for those systems obviously think that their export
> is great or at least spec compliant.
> 
> So, if you get a black screen or an error message whose fault is it?
> Actually, the parser would need to give DETAILED error messages and
> identify the exact node it choked on. Then the problem with the export
> could be reported back to the Modeling and animation corporations like
> Newtek or TGS or Discreet.....

I think we are Pretty Good about error reporting now in OpenVRML. We
could be Better.

If you want to be able to write a Perl/Python/Whatever script that will
itself be intimately involved in the parse, OpenVRML is the wrong tool
for the job. OpenVRML's parser is intended to function like a black box:
you hand it a stream, and it does it's best to load it, spewing errors
if appropriate. There are no hooks where an arbitrary application can
tie into the parsing process. That just isn't a very useful thing to do
for parsing VRML. It would introduce complexity into the parse and kill
performance. If you want a C++ VRML parser, what OpenVRML offers is an
ANTLR grammar that you modify with your own actions.

> In a couple of weeks I'll have a large number of test models for OpenVRML
> 0.10.1.
> 
> The good news is that OpenVRML 0.10.1 did as good as Cortona in displaying
> several relatively complex architectural models.

It's clear at this point that 0.11 has quite a number of regressions
with respect to 0.10 :-(. We'll fix 'em.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>