Menu
▾
▴
xpipe-developers — XPipe developers list
You can subscribe to this list here.
| 2002 |
Jan
(31) |
Feb
(20) |
Mar
(5) |
Apr
(3) |
May
|
Jun
(5) |
Jul
(33) |
Aug
(10) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|
|
From: <de...@ei...> - 2002-02-01 14:01:06
|
Hi Sean, > Great stuff. I'm looking forward to looking at this. > (Downloading netbeans...) Argghh. I've had to use netbeans for the last 2 weeks on a project in work. Be very careful about using it in conjunction with another editor. I haven't done that much digging, but it seems keeps info about auto generated code in an XML file (.Form) and if the XML and the java files get out of sync, or you overwrite the auto generated areas in another editor (netBeans locks these off; you can't simply edit them with it), netbeans may get very confused. It seems to break the once and only once principle with the XML and Java; you'll need both in cvs. Though I'm sure these irks can be made go away with enough configuring (BEA use netBeans as the heart of their Portal4 product). It's also quite demanding on memory and cpu; it's written in Swing after all ;) What's good about netbeans: 1) _great_ for gui RAD work (less so for fine tweaking); 2) ultimately configurable (you've got the source after all); 3) plays really well with cvs (the diff tool is great; I'm thinking about how to get winCVS to use it); 4) uses Ant to build the Java 5) if you _don't_ keep the app logic out of auto generated code you'll go insane, so you'll have to think model-view-controller as a matter of survival. > I was thinking of using UML sequence or state diagrams in > something like ArgoUML for XPipe editing. ArgoUML can save > out XMI which could be processed (with XPipe of course) to > create XPipe compliant pipelines. ArgoUML is cool, you might want to check how clean the XMI output is. I haven't used Eclipse. The thing about trying to build data driven Swing apps (i.e. where they're fronting for a server or a DB and sucking in XML config data) is you wind having to use reflection to do what would simple enough in other languages; tho' XML serialization in jdk1.4 should help here. David Flanagan's Java Examples in a Nutshell has a nice example of how to use reflection to drive Swing apps (it doesn't use XML, but you can see how it might be done). Regards, Bill de hOra |
|
From: Sean M. <sea...@pr...> - 2002-01-31 22:08:11
|
David, Great stuff. I'm looking forward to looking at this. (Downloading netbeans...) I think a number of IDEs out there could help reduce the development time for some GUI based XComponent/XPipe tools. I was thinking of using UML sequence or state diagrams in something like ArgoUML for XPipe editing. ArgoUML can save out XMI which could be processed (with XPipe of course) to create XPipe compliant pipelines. Eclipse (http://www.eclipse.org) is another possibility. An XPipe project-specific tool could be created using a graph editing toolkit such as the GEF library used in ArgoUML. Anybody got any suggestions for other open source graph editing toolkits for Java? Sean At 01:44 01/02/2002 +0400, David Shalamberidze wrote: >Hi All, > >About Swing based XComponent editor. >I think it should not be only editor it should provide features like >compilation, debugging, executing XPipes etc. >Also component developer should have ability to write and debug additional >code, which will be used by XComponent for instance additional Java classes >or scripts. >I am afraid that development of such IDE will be very difficult and will >take a lot of time. > >I propose to use existing IDE such Netbeans (Sun Forte) with additional >modules for XComponent support. This IDE is based on open APIs and has very >flexible infrastructure for additional modules. >This approach gives ability to use existing services of the IDE such project >manager, project tree explorer, java debugger etc. > >Netbeans is free open source project and for XComponents development will be >required only to download it and XComponent module and use it free. > >Netbeans also allows adding support for XSLT, Jython and other script >languages. > >You can see prototype of XComponent module for Netbeans at >http://xpipe.tripod.com/ >Please don't forget it is only prototype :) > >I used David Starr's draft Java implementation of XComponent. But I was >forced to place it in package (org.xpipe) because it is a requirement of >Netbeans modules specification. > >David Shalamberidze >da...@sa... > > > >_______________________________________________ >Xpipe-developers mailing list >Xpi...@li... >https://lists.sourceforge.net/lists/listinfo/xpipe-developers http://www.propylon.com |
|
From: David S. <da...@sa...> - 2002-01-31 21:45:32
|
Hi All, About Swing based XComponent editor. I think it should not be only editor it should provide features like compilation, debugging, executing XPipes etc. Also component developer should have ability to write and debug additional code, which will be used by XComponent for instance additional Java classes or scripts. I am afraid that development of such IDE will be very difficult and will take a lot of time. I propose to use existing IDE such Netbeans (Sun Forte) with additional modules for XComponent support. This IDE is based on open APIs and has very flexible infrastructure for additional modules. This approach gives ability to use existing services of the IDE such project manager, project tree explorer, java debugger etc. Netbeans is free open source project and for XComponents development will be required only to download it and XComponent module and use it free. Netbeans also allows adding support for XSLT, Jython and other script languages. You can see prototype of XComponent module for Netbeans at http://xpipe.tripod.com/ Please don't forget it is only prototype :) I used David Starr's draft Java implementation of XComponent. But I was forced to place it in package (org.xpipe) because it is a requirement of Netbeans modules specification. David Shalamberidze da...@sa... |
|
From: Sean M. <sea...@pr...> - 2002-01-31 17:35:06
|
All, Having discussed source code hierarchy organization with David Starr and others, and having had my ears burned about Java Code Conventions from various quarters :-), I have decided to bite the bullet and do a major code re-org around the domain name xpipe.net. CVS does not make it easy to rename files never mind wholesale rearrange directory structures. All the more reason to put a reasonable structure in place now that can last us into 1.0 and beyond. This process (in particular the changes in naming conventions in methods etc.) will certainly introduce bugs. It impossible to say how long it will take to get the re-org finalized so it may effect the 0.6 release slated for Sunday. More news anon. Sean |
|
From: Sean M. <sea...@pr...> - 2002-01-30 15:34:30
|
At 10:19 30/01/2002 -0500, David Starr wrote: >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. What I'd like to do is to put the XComponent Object Model stuff in now. I'm running through the stuff now. Hope to have in CVS later today. I've moved the process related stuff[1] into an archive for the moment. Sean [1] 21/01/2002 21:35 1,995 JavaXComponent.java 21/01/2002 21:41 1,393 PythonXComponent.java 20/01/2002 20:22 1,141 XComponentClassLoader.java 21/01/2002 21:41 1,327 XSLTXComponent.java |
|
From: David S. <ds...@st...> - 2002-01-30 15:22:29
|
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
|
|
From: Sean M. <sea...@pr...> - 2002-01-30 14:31:33
|
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
|
|
From: Sean M. <sea...@pr...> - 2002-01-30 13:32:46
|
At 07:36 30/01/2002 -0500, David Starr wrote: >Just thinking out loud here, what implications does this have for the >executive? Processing an XPipe is a fairly straight-forward and linear if >XComponents don't split. If they split, something has to manage the fact >that there will be multiple active XComponents same time. Yes indeed. Scheduling becomes interesting but I feel that graph structures will need to be catered for in the topology as many XML processing tasks involve routing content through different work flows. I dislike the term "workflow" because of all the connotations it brings so I'm going to try and avoid using it:-) The goal is to allow linear pipes to be easily crafted and easily executed but to allow collections of these pipes to be joined together into higher level rigs to achieve more complex data flows. The XRig level is definitely something that will be bitten off later rather than now. The primary goal now is to get linear pipes working. The secondary goal is to be able to counter the question "how do I do conditional flow processing" by punting to the XRig level of the architecture :-) regards, Sean |
|
From: Sean M. <sea...@pr...> - 2002-01-30 09:41:13
|
[David Starr] >I have been trying to mirror some of the XComponent development in Java >and this >provides an alternative means to execute an XComponent. If interested see >here from the list archives: >http://www.geocrawler.com/lists/3/SourceForge/17817/0/7615048/ I hope to have Davids work folded into the next release of XPipe. >2. The Big Aspirational Plan is probably not the best resource for >the short >term stages. >http://xpipe.sourceforge.net/Articles/Documentation/fog0000000039.html Lists >the short term deliverables. XPipes come in the anxiously awaited 0.6. I'm working on them right now... >3. Split, Scatter, and Gather are functions of the XRig, a level >above the >XPipe. Strictly speaking, Split, Scatter and Gather are just XComponents. However given that their function is to split data into chunks that can be fed down different XPipes, it is true that they are most useful in creating XRigs. Expecially Split. Scatter/Gather are really, really useful for dealing with the instance size problem often faced by XSLT/DOM programmers. I hope Scatter/Gather will be the main demo for the next release of XPipe. regards, Sean |
|
From: Sean M. <sea...@pr...> - 2002-01-30 09:36:08
|
At 16:20 29/01/2002 -0500, DuCharme, Bob (LNG) wrote:
>Hello XPipers!
>
>I downloaded xpipe0.4.zip and ran the xc0 - xc3 tests fine using Windows 98
>and Sun's Java HotSpot Client VM build 1.3.0_01.
Thanks for downloading and testing!
> I have four questions (and
>I apologize if the answers were under my nose somewhere):
>
>1. How do we tell an XComponent to use some input other than the test input,
>e.g. a foobar.xml file sitting on the hard disk?
The mainline of ExecuteXComponent.py in 0.4 is wired to run a test case.
I have changed it to run the test case if there are no command line
parameters and expect 4 parameters otherwise:
Param 1 : The Directory in which the XComponent has been installed
Param 2: Input File
Param 3 : Output File
Param 4: Log File
This will be in the CVS later today. Here is a little script that gets around
the problem by importing the ExecuteXComponent function:
# ExecuteXComponent1.py
import sys
from ExecuteXComponent import ExecuteXComponent
ExecuteXComponent (sys.argv[1],sys.argv[2],sys.argv[3],sys.argv[4])
>2. Although the Big Aspirational Plan document says that XPipes are the
>focus of the 0.4 release, and Schemas\XPipe.dtd does show me the proper
>structure of an XPipe, I don't see anything in the 0.4 distribution about
>running a pipeline. How do I use the output from one XComponent as the input
>of the next one?
I'm working on the XPipe model right now and hope to have it all up and
running by the weekend.
>3. The FAQ mentions XComponents split, scatter, gather, triggers etc., but I
>don't see these anywhere in XPipe 0.4 distribution. Where can I see
>XComponents other than xc0 - xc3?
I have some in various stages of readiness and have some work from David
Starr to fold in. Hopefully I'll have new components in by the week end.
Scatter/Gather in particular, will, I believe, make the benefits of XPipe
pipelining clear - expecially to XSLT and DOM developers hitting scaling
problems.
>4. Tell me more about executing Code with type="Exec". For example, if it's
>an Omnimark script, where would I say that Omnimark is the executable to
>run?
I hope to have this in by the weekend - using Unix tr command as an example
of an external native app. Once this works, Omnimark, Perl etc. should
be simple.
>Two points about the README file:
Thanks for the fixes.
regards,
Sean
|
|
From: David S. <ds...@st...> - 2002-01-29 23:52:26
|
Hey Bob, Probably not official answers. But as someone who's been following pretty closely, I'll help where I can. 1. ExecuteXComponent.py will execute an X Component. It's main method looks like mainly a test driver so you would have to launch a jython interpreter and then "from ExecuteXComponent import ExecuteXComponent" Then you can call ExecuteXComponent() while in the interpreter. Just look in ExecuteXComponent for the arguments. This will work for JavaClass, Jython, and XSLT XComponents. No support for execute yet. Doing this directly will allow you to use whatever input and output files you like. I have been trying to mirror some of the XComponent development in Java and this provides an alternative means to execute an XComponent. If interested see here from the list archives: http://www.geocrawler.com/lists/3/SourceForge/17817/0/7615048/ 2. The Big Aspirational Plan is probably not the best resource for the short term stages. http://xpipe.sourceforge.net/Articles/Documentation/fog0000000039.html Lists the short term deliverables. XPipes come in the anxiously awaited 0.6. 3. Split, Scatter, and Gather are functions of the XRig, a level above the XPipe. I wrote one XCOmponent that mimics the Jython program that generates HTML documentation of an XComponent. YOu can fetch it from http://www.starrconnect.com/xpipe/doc.xco . Note that my web server doesn't deliver it with the proper MIME type so to fetch it use something like wget or in a browser 'view source' then 'save as'. I believe that Sean hopes others my contribute some valuable XComponents. David -----Original Message----- From: xpi...@li... [mailto:xpi...@li...]On Behalf Of DuCharme, Bob (LNG) Sent: Tuesday, January 29, 2002 4:20 PM To: 'xpi...@li...' Subject: [Xpipe-developers] questions about using 0.4 Hello XPipers! I downloaded xpipe0.4.zip and ran the xc0 - xc3 tests fine using Windows 98 and Sun's Java HotSpot Client VM build 1.3.0_01. I have four questions (and I apologize if the answers were under my nose somewhere): 1. How do we tell an XComponent to use some input other than the test input, e.g. a foobar.xml file sitting on the hard disk? 2. Although the Big Aspirational Plan document says that XPipes are the focus of the 0.4 release, and Schemas\XPipe.dtd does show me the proper structure of an XPipe, I don't see anything in the 0.4 distribution about running a pipeline. How do I use the output from one XComponent as the input of the next one? 3. The FAQ mentions XComponents split, scatter, gather, triggers etc., but I don't see these anywhere in XPipe 0.4 distribution. Where can I see XComponents other than xc0 - xc3? 4. Tell me more about executing Code with type="Exec". For example, if it's an Omnimark script, where would I say that Omnimark is the executable to run? Two points about the README file: In Step 2, "XComponentUnitTest.py" should say "jython XComponentUnitTester.py" In "jython InstallXComponent.py XComponents/xc2.xco /test" in the readme, I would lose the / before test throughout. Why put the test file off the root? A subdirectory of the installation directory makes more sense. (Or at least add a note in step 1 that that's the path name--this isn't obvious, especially to us old folk who remember the forward slash used to indicate switches in DOS--and that you might want to install it elsewhere.) Bob DuCharme www.snee.com/bob <bob@ snee.com> see http://www.snee.com/bob/xsltquickly for info on book "XSLT Quickly" from Manning Publications. _______________________________________________ Xpipe-developers mailing list Xpi...@li... https://lists.sourceforge.net/lists/listinfo/xpipe-developers |
|
From: DuCharme, B. (LNG) <bob...@le...> - 2002-01-29 21:54:04
|
Hello XPipers! I downloaded xpipe0.4.zip and ran the xc0 - xc3 tests fine using Windows 98 and Sun's Java HotSpot Client VM build 1.3.0_01. I have four questions (and I apologize if the answers were under my nose somewhere): 1. How do we tell an XComponent to use some input other than the test input, e.g. a foobar.xml file sitting on the hard disk? 2. Although the Big Aspirational Plan document says that XPipes are the focus of the 0.4 release, and Schemas\XPipe.dtd does show me the proper structure of an XPipe, I don't see anything in the 0.4 distribution about running a pipeline. How do I use the output from one XComponent as the input of the next one? 3. The FAQ mentions XComponents split, scatter, gather, triggers etc., but I don't see these anywhere in XPipe 0.4 distribution. Where can I see XComponents other than xc0 - xc3? 4. Tell me more about executing Code with type="Exec". For example, if it's an Omnimark script, where would I say that Omnimark is the executable to run? Two points about the README file: In Step 2, "XComponentUnitTest.py" should say "jython XComponentUnitTester.py" In "jython InstallXComponent.py XComponents/xc2.xco /test" in the readme, I would lose the / before test throughout. Why put the test file off the root? A subdirectory of the installation directory makes more sense. (Or at least add a note in step 1 that that's the path name--this isn't obvious, especially to us old folk who remember the forward slash used to indicate switches in DOS--and that you might want to install it elsewhere.) Bob DuCharme www.snee.com/bob <bob@ snee.com> see http://www.snee.com/bob/xsltquickly for info on book "XSLT Quickly" from Manning Publications. |
|
From: David S. <ds...@st...> - 2002-01-22 03:57:40
|
I have replaced the .zip file at http://www.starrconnect.com/xpipe/JavaXComponent.zip The only change is addition of the ability to execute Java and Python code. Now these plus XSLT XComponents can be executed directly from the .xco file without extracting to a file. Python code is run by instantiating a Jython interpreter. Java code is instantiated through a custom class loader used to load the class data from .xco files. There is a test driver for the XComponentFactory class that can be used to execute .xco file directly. You can invoke it as: java XComponentFactory <xco file> <in file> <out file> <log file> The following need to be in the classpath: JDOM A JAXP parser Jython 2.1 Coming soon: 1) Handling of error conditions. 2) Invoking unit tests 3) Checking of preconditions and postconditions It may be a few days until I get to them. David David Starr 18 Winthrop Terrace Wayland, MA 01778 (508) 358-2975 da...@st... |
|
From: Sean M. <sea...@pr...> - 2002-01-20 19:22:17
|
David, Thanks David. I hope to get a chance to look at your work this coming week. The bad news is that I have not got the work done on XPipe that I wanted to this week so the roadmap has slipped by a week. The good news is that XPipe will be a subject at two upcoming XML events. It will no doubt creep into the panel discussion on Web Services to be held at the inuagural meeting of the Irish XML SIG - Wed Feb 8th in Dublin (http://www.xmlireland.com). XPipe is the subject of a talk I will be giving on Tuesday, 12 February in New York Details available from Walter Perry (wp...@fi...). regards, Sean At 13:36 20/01/2002 -0500, David Starr wrote: >I've placed a draft Java implementation of XComponent at >http://www.starrconnect.com/xpipe/JavaXComponent.zip > >Structurally the model parallels Sean's python model. > >For serialization/deserialization the system uses JDOM. I had considered >using one of the many data binding frameworks, but I don't know of any that >support RNG. From a maintainability standpoint I'd rather take the pain of >hand coded serialization than maintaining parallel schemata. Although that >may just be me. > >Each class implements a toJDOM method that returns a JDOM element. The >XComponent object's toXML method uses JDOM's XMLOutputter to generate XML >text. A future refactoring enhancement will be to derive each object in the >model from some superclass that implements a single toXML so that each can >generate an XML fragment. > >Each class also implements a toString for debugging purposes. Coming will >be equals and hash methods for those classes that need them. > >Error handling is not really addressed yet. I'll take care of this soon. > >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? > >If others like this approach I'll keep moving on it. First building a >classloader to load the code for Java XComponents, then moving on to the >Jython case. > >David > >David Starr >18 Winthrop Terrace >Wayland, MA 01778 >(508) 358-2975 >da...@st... > > >_______________________________________________ >Xpipe-developers mailing list >Xpi...@li... >https://lists.sourceforge.net/lists/listinfo/xpipe-developers http://www.propylon.com |
|
From: David S. <ds...@st...> - 2002-01-20 18:32:11
|
I've placed a draft Java implementation of XComponent at http://www.starrconnect.com/xpipe/JavaXComponent.zip Structurally the model parallels Sean's python model. For serialization/deserialization the system uses JDOM. I had considered using one of the many data binding frameworks, but I don't know of any that support RNG. From a maintainability standpoint I'd rather take the pain of hand coded serialization than maintaining parallel schemata. Although that may just be me. Each class implements a toJDOM method that returns a JDOM element. The XComponent object's toXML method uses JDOM's XMLOutputter to generate XML text. A future refactoring enhancement will be to derive each object in the model from some superclass that implements a single toXML so that each can generate an XML fragment. Each class also implements a toString for debugging purposes. Coming will be equals and hash methods for those classes that need them. Error handling is not really addressed yet. I'll take care of this soon. 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? If others like this approach I'll keep moving on it. First building a classloader to load the code for Java XComponents, then moving on to the Jython case. David David Starr 18 Winthrop Terrace Wayland, MA 01778 (508) 358-2975 da...@st... |
|
From: Sean M. <sea...@pr...> - 2002-01-16 12:41:59
|
At 07:37 16/01/2002 -0500, David Starr wrote: > > Ideally, I think, an IO interface for XComponents that developers can use > > but are > > not forced to use would be good. An XComponent could flag its > > conformance with > > the XPipe IO system in the XCO file. The executive could then take > > advantage of > > this to, for example, chain Output of component N to imput of > > component N+! > > bypassing > > serialization to disk. > > >That seems fair. In the absense of such an interface in both component N >and N+1, I assume the executive will create (and subsequently destroy) temp >files used in interim steps. Yes. Sean |
|
From: David S. <ds...@st...> - 2002-01-16 12:32:03
|
> Ideally, I think, an IO interface for XComponents that developers can use > but are > not forced to use would be good. An XComponent could flag its > conformance with > the XPipe IO system in the XCO file. The executive could then take > advantage of > this to, for example, chain Output of component N to imput of > component N+! > bypassing > serialization to disk. > That seems fair. In the absense of such an interface in both component N and N+1, I assume the executive will create (and subsequently destroy) temp files used in interim steps. David |
|
From: Sean M. <sea...@pr...> - 2002-01-16 11:12:11
|
At 13:55 15/01/2002 -0500, David Starr wrote: > > Suffice it to say that I believe we need to get XPipe working before we > > worry about making it work fast. I've made that mistake many > > times in the past. > > >I acknowledge the problems of premature optimization. But it might be wise >to consider a more flexible document interface to the XComponent so that >they won't have to be rewritten if/when the document conduit changes. Ideally, I think, an IO interface for XComponents that developers can use but are not forced to use would be good. An XComponent could flag its conformance with the XPipe IO system in the XCO file. The executive could then take advantage of this to, for example, chain Output of component N to imput of component N+! bypassing serialization to disk. regards, Sean |
|
From: David S. <ds...@st...> - 2002-01-15 18:50:29
|
> Suffice it to say that I believe we need to get XPipe working before we > worry about making it work fast. I've made that mistake many > times in the past. > I acknowledge the problems of premature optimization. But it might be wise to consider a more flexible document interface to the XComponent so that they won't have to be rewritten if/when the document conduit changes. David |
|
From: David S. <ds...@st...> - 2002-01-15 18:40:40
|
From: Derek Higgins [mailto:der...@pr...] > Hi David, > it seem that the file attached to this mail must have gotten > filtered out > by the mailing list or something. Would you be able to send on > too me as I > wouldn't mind > taking a look at it. > Thanks Derek the file can be found at http://www.starrconnect.com/xpipe/doc.xco Note that my web server defaults to text/html for the mime type for xco files, but this should only introduce minimal additional hassle to retrieve it. David |
|
From: Sean M. <sea...@pr...> - 2002-01-15 09:04:51
|
At 18:52 14/01/2002 -0500, David Starr wrote: >After reviewing the 0.4 System code, I have a few questions and things I >noticed. > >1) XComponentUnitTester doesn't seem to be doing anything to process >parameters. This is top of my list - both to further complete the unit tester and to show how parameters are passed into XComponents at run-time.. >2) I tried to figure out how parameters are into Java XComponents. I am >guessing that they are just passed in as -name value pairs as part of the >String vector. Is this it? Yes, that is the idea. The least intrusive way I could come up with so that XComponent developers work - for all intents and purposes - on standalone programs invoked by a "main" method with command line parameters. >3) Is it intended that XComponents will continue to perform file i/o as >opposed to StreamReader/Writer interfaces or something that wouldn't require >going to disk at every step? Yes for now. I realise that file IO is the obvious performance-related "hotspot" candidate in XPipe but I am anxious to not get concerned with optimizations at this stage. I'm writing a doc on optimization options for the Xpipe site that outlines some of the things I have played with - to considerable sucess - with the CPython versions of the XPipe stuff we have used internally for quite some time. - Shadow files (ala Python's pyc - just in time compilation to object form) - Ram disks (an excellent option in some environments) - Caching (particulary suited to pure-XSLT XPipes) - Translets Suffice it to say that I believe we need to get XPipe working before we worry about making it work fast. I've made that mistake many times in the past. >If someone's not already addressing these, I'm happy to try and dig into the >python code to try and incorporate these. But of course I'd need to know >the details on parameter passing first. I will have this done by the weekend - hopefully encorporating your JDBC XComponent. regards, Sean |
|
From: David S. <ds...@st...> - 2002-01-14 23:47:01
|
After reviewing the 0.4 System code, I have a few questions and things I noticed. 1) XComponentUnitTester doesn't seem to be doing anything to process parameters. 2) I tried to figure out how parameters are into Java XComponents. I am guessing that they are just passed in as -name value pairs as part of the String vector. Is this it? 3) Is it intended that XComponents will continue to perform file i/o as opposed to StreamReader/Writer interfaces or something that wouldn't require going to disk at every step? If someone's not already addressing these, I'm happy to try and dig into the python code to try and incorporate these. But of course I'd need to know the details on parameter passing first. David David Starr 18 Winthrop Terrace Wayland, MA 01778 (508) 358-2975 da...@st... |
|
From: David S. <ds...@st...> - 2002-01-14 18:33:45
|
Here is an XSLT XComponent that mimics Sean's python program for generating HTML documentation for an XComponent. It's a bit rough-and-ready, but it seems to work. If nothing else, it provides a slightly more intricate XComponent to play with. David David Starr 18 Winthrop Terrace Wayland, MA 01778 (508) 358-2975 da...@st... |
|
From: Sean M. <sea...@pr...> - 2002-01-12 18:21:18
|
I am pleased to announce that version 0.4 of XPipe (http://xpipe.sourceforge.net) is available for download on Sourceforge http://sourceforge.net/projects/xpipe/. New In this Release: XComponent Creator - A Jython command line utility for creating an XComponent from an .py, .xsl or .class file (CreateXComponent.py) XComponent Intaller - A Jython command line utility for installing an XComponent into a specified directory. It unpacks the code, creates Unit Test directories etc. (InstallXComponent.py) XComponent Unit Tester - a Jython command line utility for testing intalled XComponents. (XComponentUnitTester.py) The release includes three functional "null transformations" - the simplest possible XComponents. xc1.xco - Null Transformation in Java xc2.xco - Null Transformation in XSLT xc3.xco - Null Transformation in Jython Help testing/debugging this release would be gratefully received. Instructions for testing the software are included in the README. Sean |
|
From: David B. <dav...@op...> - 2002-01-10 23:46:42
|
Always like the idea of working on a test application to see how a philosophy pans out in practice -:) Just a thought but how about a very simple DocBook word processor? |
1 message has been excluded from this view by a project administrator.
