[news.eclipse.technology.equinox] Re: Work items posted

["Jeff McAffer" <jeff_mcaffer_REMOVE@xxxxxxxxxx>]

Meta note:  Lets stick to plain text posts in the newsgroup.

"Kevin" <supreme_java_guru_1@xxxxxxxxx> wrote in message
news:b6j2lq$9ql$1@xxxxxxxxxxxxxxxx

....I think Eclipse, OSGi and other approaches (JEdit, IDEA, etc) all have
some good things in them. But mostly, I wanted a very tiny engine that could
easily be embeded and used in any type of application, not just GUI. I found
with Eclipse at the time, it was built around SWT and the plugin.xml format
was heavily tied into the GUI to allow lazy activation of plugins when menu
items or buttons were clicked. I have adopted the lazy

<jm>Some clarification... The Eclipse runtime is not GUI based or related.
The plugin model is completely devoid of any GUI notions.  There are many
applications of Eclipse which are entirely headless.
</jm>

The XML Pull Parser is not a 100% XML compliant parser in that it doesn't do
DTD or XML Schema validation, nor is it by any means the normal DOM or SAX
type of code to parse the xml file. It is however faster than every parser
out there, at least from the last tests done on it, it also uses less memory
than SAX2 parsing, and the code is extremely easy to figure out and work
with. I would think the parsing of the plugin.xml files, and any other .xml

<jm>This is interesting.  Currently Eclipse uses Xerces for all its XML
parsing.  The Eclipse requirements are very modest and Xerces is largely
overkill (as well as being 1.2MB on disk).
</jm>

So, while I'd like to keep on using my own tiny little "kernel" of an engine
that provides the basics of eclipse and OSGi with the simplicity of a few
lines of code to develop a plugin, I'd also like to possibly help out with
the OSGi/Eclipse marriage (I assume that is what Equinox is about?) to see a
better overall architecture, that

<jm>The goals of Equinox are mentioned on the web site.  An Eclipse/OSGi
marriage is not a stated goal though it may well be an outcome.  The
ultimate goals are centered around dynamic plugins, increased flexibility,
service models, ...  We'll use/create whatever technology helps reach those
goals.
</jm>

Jeff