Re: [Xpipe-developers] draft Java implementation of XComponent for comment

[Sean M. <sea...@pr...>]

Some time ago, (I'm in catch-up mode), David wrote:

>>For discussion, I have also subclassed XComponent with three classes
>>JavaXComponent, XSLTXComponent, and PythonXComponent.  There is a
>>XComponentFactory that can be used to create the correct XComponent object.
>>It is my intent to be able to invoke the XComponent directly through a
>>process() method.  I have implemented this for the XSLTXComponent, but the
>>other two will take some work.  To process an XSLT XComponent, all you'd
>>have to do is:
>>
>>         XComponentFactory fact = new XComponentFactory ();
>>         XComponent xc = factory.getXComponent ("xc0.xco");
>>         xc.process ({in.xml; out.xml});
>>
>>Of course, if all this works, the system won't be required to extract code
>>and other resources won't need to be extracted to disk to execute or test
>>XComponents.  Thoughts?

The approach taken to date has been to extract components into persistent 
storage
prior to execution. Although it is not strictly necessary to do this for 
the purposes
of the executable code, it is nice to "explode" out resources from the 
Resources section
so that they can be accessed by the executing code as ordinary files i.e. 
Schemas, DTDs, mapping
tables etc.

The simplest possible model is to instantiate all the required pieces for 
an XComponent to work
onto the filesystem - one directory per XComponent. This is the easiest to 
conceptualize and
easiest to debug.

I fully expect there will be numerous optimizations that can be implemented 
to reduce/remove
filesystem IO once we have it all working.

Sean