Subject: RE: [xsl] Saxon for windows? From: Pieter Reint Siegers Kort <pieter.siegers@xxxxxxxxxxx> Date: Fri, 3 Jun 2005 12:01:28 -0500 |
You call it debugging, I called it analysing. It allows for terminating the chained process if something goes wrong. Cheers, Pieter -----Original Message----- From: M. David Peterson [mailto:m.david.x2x2x@xxxxxxxxx] Sent: Friday, June 03, 2005 11:58 AM To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx Subject: Re: [xsl] Saxon for windows? > Full control - StdErr is also captured just like StdOut. Both are > analysed before further processing, using C#. Knowing that an error occurred and handling this error inside of the process when it occurs are separate things? Having the information after the fact doesn't allow you the ability to go back to a process to then properly handle things. Once the process is complete, that's it. In cases of debugging just having the information may be enough. But debugging is part of the development process. When in a production environment and things go astray just knowing that they've gone astray after the fact doesn't do you any good whatsoever. On 6/3/05, Pieter Reint Siegers Kort <pieter.siegers@xxxxxxxxxxx> wrote: > > 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/ > > -- <M:D/> M. David Peterson http://www.xsltblog.com
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] Saxon for windows?, Pieter Reint Siegers | Thread | RE: [xsl] Saxon for windows?, Pieter Reint Siegers |
RE: [xsl] Saxon for windows?, Pieter Reint Siegers | Date | RE: RFC: [xsl] Recursive Template I, Bovy, Stephen J |
Month |