[nebulastudio-discuss] nXML, nJava, and nWrapper
bruce at cubik.org
Sat May 15 00:15:08 PDT 2004
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
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
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:
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
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. :)
More information about the nebulastudio-discuss