[nebulastudio-discuss] nXML, nJava, and nWrapper

[Bruce Mitchener]

Hi Andre,

Andre Mikulec wrote:
> So let me try to understand this.

Sure thing.  This is largely my fault I suspect since half of the people 
on this list know about these various bits and pieces from talking with 
me over the last couple of months.  I'll try to make this all clear now.

> Is it that I can use nJava, nXML, or nWrapper to use Eclipse to talk 
> throug (nJava or nXML or nWrapper) to talk to  nebula 2?

nJava is largely generated code that lets you use the Nebula 2 script 
API from Java.  The code that is generated consists of Java source files 
and a good amount of C++ glue that uses JNI to manage calls from native 
Java methods into the C++ Nebula code and back.  It handles all runtime 
considerations like translating datatypes and so on from nArgs to Java 
and back.

nXML isn't really at play here.  I think what you're referring to is the 
XML metadata that we've been talking about needing.  I'll come back to 
this soon.

nwrapper is currently a C++ program that loads the Nebula object system 
metadata (nClass, nCmdProto objects) and crawls through the data on them 
and generates language bindings to the script API.  This is what is used 
to generate the Java/C++ sources for nJava.

The problem with nwrapper is a simple one:  It is deficient because the 
data that we have at runtime isn't sufficient to generate wrappers with 
enough detail/information as we'd like.

The way that I wanted to solve this was to use metadata expressed in XML 
rather than using the data available at runtime.  I posted about this in 
these two posts:

http://lists.cubik.org/pipermail/nebulastudio-discuss/2004-May/000001.html
http://lists.cubik.org/pipermail/nebulastudio-discuss/2004-May/000009.html

The plan changed a fair bit today though thanks to the actions of Dark 
Dragon (Ivan).  He provided a proof of concept for retrieving the data 
that we wanted from comments in the _cmds.cc files in the existing 
sources.  Not all of the information is present, so we'll need to add 
some tags for that data.  His script (which he's posted to the list) 
generates XML files that we'll be able to use for nwrapper (and other 
things).

He may also be rewriting nwrapper to use this XML data to generate the 
language bindings.  If he does, nwrapper will switch to being a Python 
program rather than C++.

With any luck and he and I having sufficient amounts of time in the 
coming days, we'll be able to have this up and running soon.

> Can I use these these instead of (or along with) microtcl, npython, 
> nlua, ... etc?

nJava can be used in place of microtcl, npython and nlua for actual 
programming tasks.  It doesn't provide any way though to fill in as a 
script server, so it can't be used for persistence or on the console. 
I'm fine with this for now since what I want nJava for is the 
integration with Eclipse.

> Is the Nebula2 NOH Eclipse browser a good example of this?

Not really.  It just uses nJava in its current state to display a view 
of the NOH, but without any real data other than node names.  It is 
entirely just a proof of concept to demonstrate (to me) that I got the 
other plugins working and solved various problems along the way with 
basic Eclipse/Nebula integration.

A real NOH browser will use nJava *AND* the XML data.  The XML data 
provides some higher level data that is used to know what properties and 
object exposes and how they should be displayed in the UI for editing 
and viewing.  It isn't enough to know that something is "4 floats" or a 
"vector4".  We need to know that it is a color, or a position, or a 
quaternion.  That's the type of data that we'll need to get from the 
metatdata stored in the XML files.  And that's why the XML files are so 
important beyond just being useful for nwrapper.  And lastly, that's why 
it is so important that we get this stuff done now and out of the way.

Does this clarify things at all?  For now, I need to get home and sleep. :)

  - Bruce