RE: Saxon for windows?

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(_dot_)david(_dot_)x2x2x(_at_)gmail(_dot_)com] 
Sent: Friday, June 03, 2005 11:58 AM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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(_dot_)siegers(_at_)elnorte(_dot_)com> 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(_at_)saxonica(_dot_)com]
Sent: Friday, June 03, 2005 11:36 AM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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(_dot_)siegers(_at_)elnorte(_dot_)com]
Sent: 03 June 2005 16:21
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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(_at_)saxonica(_dot_)com]
Sent: Thursday, June 02, 2005 3:49 PM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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/



--~-----------------------------------------------------------------
- XSL-List info and archive:  
http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--

--~-----------------------------------------------------------------
- XSL-List info and archive:  
http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--




--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--



--
<M:D/>

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

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--