[Ocd-developers] Re: OCD and your comments...

[Jon A. M. (JAM) <jma...@co...>]

Ted,

My apologies for not writing back after a day or so like I had
said -- the holidays caught up with me. ;-) Anyway, Deane Richan
is still on break I think but I'm sure he'll want to discuss your
comments and ideas about OCD in depth, and see about you helping
out if that's what you want to do.

I believe that you mentioned OSGi, that you had written an
implementation of it, and suggested that OCD adopt some of its
ideas.  I looked up the OSGi spec and it seems to be similar to
what Deane was doing with the OCD services concept.  One thing I
like about the OSGi is that the 'bundles' register the components
that they contain with the system.  I think this would be a
better way that how it is currently done in OCD.

On the other hand, the way that the OSGi spec puts information in
the bundle jars seems pretty weak.  From what I could tell, it
adds certain entries in the manifest to hold all of the data
about the bundle, what other bundles are needed, what packages to
export, etc.  From just glancing at it, a lot of the information
mirrors that in a JNLP file -- parameters, versions, other
resources, native code libraries, and so on.  The main difference
seems to be using BNF instead of XML to format the data.

You also mentioned that you tried to implement a services
framework on top of Web Start, but that Web Start was not able to
add resources to already-running code.  One of the next things to
add to the JNLP code in OCD is the ability to link a JNLP file to
another already loaded file.  Currently we have a hack that
allows the different OCD services to be loaded separately into
the same classloader/namespace.  This should make the JNLP code
able to support a services framework.

If one was to implement an OSGi framework as part of OCD, my
suggestion would be to essentially map the OSGi bundles to JNLP
files and we can extend the XML file format (or the JNLP client
classes) for whatever information OSGi has that cannot be stored
already as JNLP.  It's quite a bit more complicated to support
more than one type of execution environment in Java, as you know,
because there are only one of the security manager and policy. 
The two systems run together and make a mess IMHO, so the options
are either that mess, make an 'ubersystem' to allow both to
co-exist, or make one conform the other.

As far as NetBeans and Eclipse are concerned, I haven't used them
enough to really comment on how they create an environment by
plugging in separate code.  I think that these show that this
kind of environment can be used to great effect when there is an
overall direction (ie, making a full-featured IDE).  However,
NetBeans at least is also very slow and bloated, likely due to
just this combining of different pieces.

I think it is good to keep that in mind that making an
environment based on small pieces that hook together is very
powerful but may not actually fit the user's needs.  As a rough
analogy, a lot of perl was essentially hard-coded into the
language to directly call C routines and whatnot.  As a result it
was very fast and efficient.  On the other hand, shell scripts do
basically the same thing but are much slower and less efficient
(and no more powerful since perl can call external commands). 
And people picked perl hands down.

Anyway you should discuss your ideas with Deane Richan, because he
is the one that did the services and GUI framework part of OCD. 
I'll probably be helping out with those parts to some degree, but
making the JNLP client part more compatible with Web Start is a
high priority.

P.S. Deane - I disabled the forums as Ted suggested and made the
ocd-developers list accessible to the public.  I've included
Ted's post below if you haven't seen it yet.

Jam

 Ted Stockwell wrote:
 > Hi all,
 > 
 > I think the OCD project is very timely. I think that this kind
 > of project is very much in need right now. Though most
 > developers don't seem to think that Java has much of a future
 > on the client, I have convinced myself that a correctly
 > architected Java client can bring functionality to the desktop
 > that no other enviroment can touch.
 > 
 > I thought I'd drop you a note about my own efforts in this
 > area and see if there is some common ground between your
 > efforts and mine. I would like to participate if I can.
 > 
 > For the better part of a year I have been working in my spare
 > time to create an application development and deployment
 > framework with many of the same goals that you have set for
 > OCD. Specifically: automatic updates, pluggable services API,
 > GUI framework for easily creating applications. I consider
 > NetBeans (http://www.netbeans.org) and Eclipse
 > (http://www.eclipse.org ) to be fine examples of the kind of
 > applications that I want to create (except that I want to
 > create generic business application, not IDEs). These
 > applications can automatically update themselves, have plugin
 > frameworks, and each has its own GUI framework that makes it
 > easier to develop UIs for the application domain.
 > 
 > After creating applications with Java Web Start and NetBeans I
 > finally settled on Eclipse (http://www.eclipse.org).
 > 
 > Here's why...
 > 
 > ...I found it too difficult to implement a basic service API
 > on top Java Web Start. My idea of the perfect service/plugin
 > API is something along the lines of OSGi
 > (http://www.osgi.org). At one point I released an
 > implementation of the OSGi 1.0 specification
 > (http://servicetango.sourceforge.net).  Since JWS controlled
 > the runtime environment so tightly I could not figure out how
 > to extend an already deployed application.
 > 
 > ...Anyway, after banging my head on JWS for a while I then
 > discovered NetBeans. NetBeans has its own proprietary update
 > mechanism a plugin API and a GUI framework. Unfortunately I
 > found NetBeans extremely difficult to change into a generic
 > business application framework. The basic plugin and GUI
 > frameworks are not very modular and I found it extremely
 > difficult to change NetBeans into something that I could use
 > to develop generic business applications.
 > 
 > ...then I found Eclipse several months ago.  I think that
 > Eclipse is about as nearly perfect all-around framework for
 > all kinds of development as you'll find right now (maybe OCD
 > could be better!).  It has its own update mechanism, a very
 > clean plugin mechanism, and a very fine GUI framework that
 > make it easy for plugins to add new views, menus, and toolbars
 > to an application. The biggest problem with Eclipse is that
 > its GUI framework was not built using AWT or Swing, it uses a
 > widget libray called SWT. No problem for me though, I've
 > ported the Eclipse GUI framework to Swing and I use Eclipse's
 > update and runtime plugins as they are.
 > 
 > Anyway, in the meantime I'll be hanging out here and taking a
 > closer look at OCD.
 > 
 > best regards,
 > ted stockwell