RE: [xsl] Saxon for windows?

Subject: RE: [xsl] Saxon for windows?
From: Pieter Reint Siegers Kort <pieter.siegers@xxxxxxxxxxx>
Date: Fri, 3 Jun 2005 11:49:03 -0500
> How does the Java VM get initialized: are you incurring the start-up costs
for each transformation, or do you have a way of amortizing them?

Not yet, but I'm working on a way to initialize the Java VM at the same time
the .NET FW gets initialized. So once it runs all things should be 'ready to
go'  - this of course includes support for other (non-Java) based
processors. I haven't done any testing in that area yet though. The same
goes for .NET though - but once settled, consequent transformation is done
without any delay.

> How much control does the client application have over error handling and
reporting?

Full control - StdErr is also captured just like StdOut. Both are analysed
before further processing, using C#.

Cheers,
Pieter

-----Original Message-----
From: Michael Kay [mailto:mike@xxxxxxxxxxxx] 
Sent: Friday, June 03, 2005 11:36 AM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: [xsl] Saxon for windows?

OK thanks for the information. It means you're passing source XML around
which is not going to be as efficient as piping SAX events, but it's
probably OK for most purposes.

How does the Java VM get initialized: are you incurring the start-up costs
for each transformation, or do you have a way of amortizing them?

How much control does the client application have over error handling and
reporting?

Michael Kay
http://www.saxonica.com/


> -----Original Message-----
> From: Pieter Reint Siegers Kort [mailto:pieter.siegers@xxxxxxxxxxx]
> Sent: 03 June 2005 16:21
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE: [xsl] Saxon for windows?
> 
> Hi Michael,
> 
> HTTP requests work but performance would be hurt. 
> 
> 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).
> 
> As said, I'm still finishing up things, but I may be opensourcing this 
> project eventually (if there's enough interest in it of course). For 
> developers, it will mean instant support for XSLT2, XPath2, and 
> XQuery1 on the .NET platform native to the processor being used. I 
> think that's the main benefit, and the other is that support for each 
> processor can be maintained in the same channels.
> 
> Cheers,
> Pieter
> 
> -----Original Message-----
> From: Michael Kay [mailto:mike@xxxxxxxxxxxx]
> Sent: Thursday, June 02, 2005 3:49 PM
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE: [xsl] Saxon for windows?
> 
>  
> > For .NET on Windows, I'm using Saxon to run natively under
> .NET to get
> > early support for XPath2, XSLT2 and XQuery1. Basically, I use a 
> > background process that runs in it's native environment -
> for Saxon,
> > that is the Java runtime.
> > The process runs in the background and I just capture its
> output while
> > being able to do other things in my application - it's completely 
> > independent.
> 
> I'm interested to know more detail about the way you are communicating 
> between the .NET client application and the Java server application.
> 
> I've suggested in the past that people should do this by running the 
> transformations in a web server and invoking them by means of HTTP 
> requests, but you seem to be going for a closer coupling than this. 
> Any chance of a more detailed write-up?
> 
> Michael Kay
> http://www.saxonica.com/

Current Thread