Lists Home |
Date Index |
:D It seems that the entire point of SXPipe was not to see how much
it could be and instead how much it could do with the minimal amount
of features possible. He definitely did an excellent job of
showcasing that power can exist within a framework even a minimalist
would have had a tough time adjusting to.... which ironically would
have showcased that even a minimalist is able to cut a few more things
out of his/her life and still get by just fine :)
I will definitely be watching the flipside "PhatKatt" you have planned
as it this could very easily prove that the minimalistic approach is
more than just a lifestyle... its a trendy lifestyle that gets old and
boring and has been given the boot... apparently a hard boot in this
case (come on, give me at least 2 point for that one... 1.5? Distract
the guys with the baseball bats headed my way while I slip out the
back? Perfect! Thanks :)
On 4/21/05, Alan Gutierrez <email@example.com> wrote:
> * M. David Peterson <firstname.lastname@example.org> [2005-04-21 14:27]:
> > Alan, out of curiosity have you spent any time studying Norman Walsh's
> > SXPipe project?
> > from the first paragraph of http://norman.walsh.name/2004/06/20/sxpipe:
> > "SXPipe is a language for building Simple XML Pipelines and a Java
> > toolkit that implements it. This is hardly a new idea; a quick web
> > search will turn up a number of similar projects. I've written
> > elsewhere about why I did it and why I think pipelines are important.
> > This essay just describes SXPipe."
> Yup. Relay/Varsity is a little more advanced that SXPipe. SXPipe, IIRC,
> moves documents from one process to the next, while Relay will
> link streams to streams, without materialization. It will
> materialize documents as needed, for an XSLT processor for example.
> Norman can correct me, but I think SXPipe was a proof of
> concept, and he left it at that stage.
> Relay/Varsity includes caching of documents, caching of
> partially configured processors (i.e. compiled XSLT transforms),
> and a straight-forward dependency mechanism, that cause
> dependenices to be inherited from cached documents, and across
> Relay/Varisty is much smaller than Cocoon, and has far fewer
> dependencies. It is easy to add a processor to Relay by
> implementing a few well defined interfaces. Confiugration via
> the Varisty container is done using constructor or setter
> injection, specified in an XML file. Caching is pretty much
> automatic, as are dependencies, if you use stock protocols.
> Can't compare to Obreon OXF, since I've not worked with it. Last
> I checked it was proprietary, but it turns out they released it
> open souce back in August.
> Alan Gutierrez - email@example.com
> - http://engrm.com/blogometer/index.html
> - http://engrm.com/blogometer/rss.2.0.xml
:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist