Re: [xsl] Saxon for windows?

Subject: Re: [xsl] Saxon for windows?
From: "M. David Peterson" <m.david.x2x2x@xxxxxxxxx>
Date: Fri, 3 Jun 2005 10:32:46 -0600
Yeah, the Web Service approach is an excellent approach if your
talking one off transforms that are coming from multiple requesting
sources.  A well designed Web Service engine can produce fantastic
results for a large multitude of requesting clients.  But if you're
talking about chaining together transformations via a Web Service
implementation this is something that would obviously be something to
be leary of.

This is not to down play Web Services from a general stand point.  In
many ways they can be quite preferable in that you simply have no
concerns as far as platform compatibilities etc...  but in regards to
performance... you've allready nailed it so no need to extend.

On 6/3/05, Barry Lay <blay@xxxxxxxxxxxxxxxxxxx> wrote:
> The XSL-as-web-service is intriguing but I do have some concerns about a
> command-line processor.  The comment George makes about the JVM startup
> overhead can be extended to most things run from the command line -
> there will be system-related activity that has little to do with the
> work that will be incurred each time.  If this is a concern for XSLT the
> processor can be properly hosted within the web server.  Saxon is ideal
> for this as it is Java based.  It would be fairly straightforward to
> create a web service for this purpose that could be dropped into a J2EE
> container and run on whatever kind of platform you like (Windows, Linux,
> Unix, Mac, etc.), and it doesn't have to be the same OS as the client.
> With Saxon's support for pipelining transformations some of those
> concerns could be addressed as well.  My main concern with the web
> service approach in general is the amount of data that would need to be
> transmitted across the network.  That may be the real limiting factor in
> this.
>
> Barry
>
> George Cristian Bina wrote:
>
> > Hi Pieter,
> >
> > > It's actually quite simple. I'm using a process class which allows
> > me to
> > > capture StdOut and StdErr, and that runs a process in the
> > background. The
> > > background process can be anything that runs via a command line, and
> > the
> > > best is that it runs completely independent (in Windows this just
> > means on
> > > another thread). While threads compete with each other for CPU time,
> > when
> > > the process runs, the main thread just waits for its output, which
> > means
> > > that the child thread can use all CPU available, thus maximum
> > performance is
> > > guaranteed (under normal circumstances and no other tasks running
> > assumed).
> >
> > What about the java start up time? You will add that at each run.
> > And if you run the transformation only once then I think you will not
> > get the best of Java either - I always hear that if you want to
> > measure how much time a stylesheet takes for processing you should not
> > look at the times of the first runs.
> >
> > My 2 cents...
> >
> > Regards,
> > George
> > ---------------------------------------------------------------------
> > George Cristian Bina
> > <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
> > http://www.oxygenxml.com
>
>


--
<M:D/>

M. David Peterson
http://www.xsltblog.com

Current Thread