Re: nio development in Jawin

Hi Josh,
See mixed in comments
Josh Passenger wrote:

> Hi Roger,
>
> Plugging in another transformation engine like Saxon should be simple and
> will probably just involve adding a -D system property tot the command
> line
> and perhaps updating the classpath in the manifest.mf file inside the
> type
> browser jar file:
>
> All of the transformation code is completely contained in this class:
>
> package org.jawin.browser.xsl;
>
> import java.util.HashMap;
> import javax.xml.transform.*;
> import javax.xml.transform.stream.*;
> import java.io.*;
> import org.w3c.dom.Node;
> import javax.xml.transform.dom.DOMSource;
>
> import org.jawin.browser.config.ConfigManager;
> import org.jawin.browser.log.Log;
>
> /**
> * Manages on the fly XSL transformations of XML and transparent
> caching of
> * loaded and compiled XSL stylesheets
> *
> * Use of this class implies Xalan (or another XSLT processor)
> * is available on the classpath.
> *
> * Download the latest version or Xalan from http://xml.apache.org
> *
> * Due to intended useage, this class may not be thread safe for
> concurrent
> * additions of new stylesheets.
> *
> * <p>Title: Jawin Code Generation GUI</p>
> * <p>Description: GUI for exploring type libraries and generating Java
> code</p>
> * <p>Copyright: Copyright (c) 2003</p>
> * <p>Company: Open Source Incentive</p>
> *
> * @author Josh Passenger
> * @version 1.0
> */
>
> public class TransformationManager
> ....
>
> There are some other dependencies on Xerces as I wrote some SAX
> parsers for
> the config files, nowadays I just use XStream, I haven't written SAX
> parser
> code since I found that!
>
> I see saxon is moving towards a split commerical full schema
> conformance and
> a freebie light version with minimal conformance.

I don't think we need the schema based version.  The dtd version is
fully XSLT 2.0 and XPath 2.0 functional.  Xalan is dormant and I doubt
will ever become schema based until a group wants open source for it
too.  Since Java has the javax.xml.transform packages
http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/transform/package-summary.html
included switching transform factories is like you say relatively
simple.  Remember the saxon guy Micheal Kay started xalan but went away
in disgust over programming style/design and started saxon.

>
> Could be a bit of a hassle to upgrade to Saxon with fighting between VM
> patched up with Xerces and Xalan in the lib endorsed directory per Xalan
> reccommended installation, that coupled with Saxons dependancy on
> JAXP.....
>
> What features in XSL 2.0 are you using, I haven't really looked at the
> latest spec.  Would moving to 2.0 confirmance require updates to the XSL
> versions in the stylesheets too?

Particularly tunneling parameters and other goodies.  Also XPath 2.0 has
improved and new functions.  Saxon runs either XSLT 1.0 or 2.0
stylesheets.  The current set of style sheets will remain as they are.
I will copy and start another set for nio till nio catches up and passes
the original marshalling.

>
> Performance issues in XSL transformations are usually solvable with some
> judicious use of xsl:key etc
>
> I'll leave it with you.  The nio stuff looks pretty interesting, good
> luck
> with it =]
>
> Josh
>
>>
>> I'm seeing quite a paradigm shift in marshaling possible with the
>> application of nio.  Nobody would be upset if Java 1.3.x .  is no longer
>> supported?  Does anybody extend DispatchPtr by hand?  The old
>> functionality would still be there but to get the benefits of nio,
>> updating classes extending DispatchPtr by hand could be a lot of work.
>> The Type Browser method will just require you to perform another
>> transform.using another set of stylesheets.
>>
>> There is much info we are not using from the type info xml and
>> transforms.  Rather than push everything on a flat marshaling stream,
>> much direct memory can be employed via nio to build DISPARAMS up with
>> low overhead.  This would remove all the checking and building of
>> variants on both the Java and Jawin native side.
>>
>> I'm thinking of also creating a family of invoke methods:
>> invokeIntMethod
>> invokeIntArrayMethod
>> invokeShortMethod
>> invokeDoubleMethod
>> invokeObjectMethod
>> ...
>> invokeVoidMethod
>> for even more optimization.  For each of these the native side will be
>> completely new code.  The new DISPARAMS marshaling would readily allow
>> for the COM object to construct and return arguments.  Strings can be
>> resized. Further the rest of the arguments will be independent and need
>> not be copied around.
>>
>> Also Josh, would it be a good idea to apply Saxon8.x instead of xalan?
>> I'm doing all my other xslt with XSLT 2.0.  Great speed and great new
>> functionality in the stylesheets.
>>
>> More later,
>>
>> Roger
>>
>> Roger I Martin PhD wrote:
>>
>>> Hi.
>>>
>>> Morten, you are a fantastic project organizer!  Things look well
>>> maintained and things work.  I just upgraded my Platform SDK and the
>>> Ant
>>> script is nice.
>>>
>>> How should we develop/maitain the nio version?  Java version? support
>>> jdk 1.3 until the nio version reaches and passes in functionality? On
>>> the Java side the nio version can use the current as base classes
>>> and we
>>> set the ant compile to 1.3 or 1.4>.  On the cpp side I'm not certain.
>>> Compile flags?  Gets ugly especially if the nio bores down thru
>>> http://cvs.sourceforge.net/viewcvs.py/jawinproject/jawin/cpp/jawin/StreamOnMemory.h?view=markup
>>>
>>>
>>> for example.
>>>
>>> One thing it will give us is speed and less work to do about byte
>>> endian.
>>>
>>> I'm also starting to have some success with the jawt on another project
>>> and am looking to use it in Jawin.
>>>
>>> Resizing a buffer may be problematic.
>>> http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/functions.html#nio_support
>>>
>>>
>>> I'm experimenting...
>>>
>>> Any other areas of interest to anyone?
>>>
>>> -Roger
>>>
>