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

[David S. <ds...@st...>]

No Worries.  AS I mentioned, the execution portion is pretty much there for
proof of concept.  I had finished the object model that I said I would write
and wanted to try a few things out.  The object model is still there and
fully functional, simply ignore all of the classes derived from XComponent
and the XComponentFactory.

I saw your note indicating that you were going to try and integrate some of
this stuff.  I'm not sure that it fits well yet.  Can you give me a roadmap
of how you see stitching things together.  Then I can probably help neaten
up some of the stuff I've written to ease the integration.  If I hear from
you I can try and get a few hours in today.  Then I'm off to client sites
for the next few days and will be pretty swamped.

David

> -----Original Message-----
> From: xpi...@li...
> [mailto:xpi...@li...]On Behalf Of Sean
> McGrath
> Sent: Wednesday, January 30, 2002 9:31 AM
> To: xpi...@li...; da...@st...
> Subject: Re: [Xpipe-developers] draft Java implementation of XComponent
> for comment
>
>
> 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
>
>
> _______________________________________________
> Xpipe-developers mailing list
> Xpi...@li...
> https://lists.sourceforge.net/lists/listinfo/xpipe-developers