You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by Raul Benito <ra...@apache.org> on 2005/11/25 19:17:04 UTC
xmlsec 1.3 released... and now what's left.
Hello Everybody,
After the painful release of the xmlsec(mainly because of the
updating of the web page, and deadlines in my "day" job), I begin to
wonder where the java xml sec should lead.
>From my area of expertise, performance:
The fast path (URI selection, only enveloping transformation) is as
fast as it can gets(about 10% overhead of plain serialization and
digesting), it can only get better with JCE(70% of execution time)
speed ups (Juice any one??).
Anyhow perhaps is time to improve performance in the slow(xpath
transformation) path. with a little help we can get rid off the slow
circunventbug call.
Or perhaps is better to pursue newer fields, I having playing with
SAX and the results are impressive, documents that the DOM library can
not ever dream manage the SAX handles without any memory adjustments,
and fast as hell.
But SAX is not the api of mode anymore perhaps is better to take a
look Stax and begin to work on it. It seems that are more projects
using Stax than sax nowadays (axis, xmlbeans,...).
What do you think? Where we should focus our efforts performance wise????
And that's not all, jsr 105, the neglected encrypted part, xkms....
New transformations, c14ns, j2me, etc... But that's a discussion, for
other thread.
Regards,
Raul
--
http://r-bg.com
Re: xmlsec 1.3 released... and now what's left.
Posted by Raul Benito <ra...@apache.org>.
On 11/26/05, Venu <K....@sun.com> wrote:
> Hello Raul,
>
> Raul Benito wrote:
> > Hello Everybody,
> > After the painful release of the xmlsec(mainly because of the
> > updating of the web page, and deadlines in my "day" job), I begin to
> > wonder where the java xml sec should lead.
> >
> > From my area of expertise, performance:
> > The fast path (URI selection, only enveloping transformation) is as
> > fast as it can gets(about 10% overhead of plain serialization and
> > digesting), it can only get better with JCE(70% of execution time)
> > speed ups (Juice any one??).
> > Anyhow perhaps is time to improve performance in the slow(xpath
> > transformation) path. with a little help we can get rid off the slow
> > circunventbug call.
> > Or perhaps is better to pursue newer fields, I having playing with
> > SAX and the results are impressive, documents that the DOM library can
> > not ever dream manage the SAX handles without any memory adjustments,
> > and fast as hell.
> > But SAX is not the api of mode anymore perhaps is better to take a
> > look Stax and begin to work on it. It seems that are more projects
> > using Stax than sax nowadays (axis, xmlbeans,...).
> >
> Are you suggesting you want to get rid of DOM , can you elaborate a bit
> ? Canonicalizers are easy to build using StAX writer
> API's.
>
High Venu,
I'm not suggesting getting rid of the DOM API but I think that there
are domains that will work faster and slimmer with a Stax/SAX API than
with DOM API(WS mainly and perhaps j2me),
I was suggesting doing something similar to what I suggest in here
http://issues.eu.apache.org/bugzilla/show_bug.cgi?id=32657
I have blog about my ideas in http://r-bg.com/apache .
But some other seems to get to the same point as me(It seems after
published after my blogging but I think they gets there indepently, it
is a obvious solution indeed)
http://www.cs.indiana.edu/~welu/c14n_hpdc05.pdf
So. I think that we shall provides to APIs for the signature
creation/verification (not just c14n) one for trees and other for
streaming.
What do you all think?
> Regards
> Venu
>
>
--
http://r-bg.com
Re: xmlsec 1.3 released... and now what's left.
Posted by Venu <K....@Sun.COM>.
Hello Raul,
Raul Benito wrote:
> Hello Everybody,
> After the painful release of the xmlsec(mainly because of the
> updating of the web page, and deadlines in my "day" job), I begin to
> wonder where the java xml sec should lead.
>
> From my area of expertise, performance:
> The fast path (URI selection, only enveloping transformation) is as
> fast as it can gets(about 10% overhead of plain serialization and
> digesting), it can only get better with JCE(70% of execution time)
> speed ups (Juice any one??).
> Anyhow perhaps is time to improve performance in the slow(xpath
> transformation) path. with a little help we can get rid off the slow
> circunventbug call.
> Or perhaps is better to pursue newer fields, I having playing with
> SAX and the results are impressive, documents that the DOM library can
> not ever dream manage the SAX handles without any memory adjustments,
> and fast as hell.
> But SAX is not the api of mode anymore perhaps is better to take a
> look Stax and begin to work on it. It seems that are more projects
> using Stax than sax nowadays (axis, xmlbeans,...).
>
Are you suggesting you want to get rid of DOM , can you elaborate a bit
? Canonicalizers are easy to build using StAX writer
API's.
Regards
Venu
Re: xmlsec 1.3 released... and now what's left.
Posted by Davanum Srinivas <da...@gmail.com>.
Sean,
+1 from me.
-- dims
On 11/28/05, Sean Mullan <Se...@sun.com> wrote:
> Raul Benito wrote:
> > Hello Everybody,
> > After the painful release of the xmlsec(mainly because of the
> > updating of the web page, and deadlines in my "day" job), I begin to
> > wonder where the java xml sec should lead.
> >
> > From my area of expertise, performance:
> > The fast path (URI selection, only enveloping transformation) is as
> > fast as it can gets(about 10% overhead of plain serialization and
> > digesting), it can only get better with JCE(70% of execution time)
> > speed ups (Juice any one??)
> >
> > Anyhow perhaps is time to improve performance in the slow(xpath
> > transformation) path. with a little help we can get rid off the slow
> > circunventbug call.
> > Or perhaps is better to pursue newer fields, I having playing with
> > SAX and the results are impressive, documents that the DOM library can
> > not ever dream manage the SAX handles without any memory adjustments,
> > and fast as hell.
> > But SAX is not the api of mode anymore perhaps is better to take a
> > look Stax and begin to work on it. It seems that are more projects
> > using Stax than sax nowadays (axis, xmlbeans,...).
> >
> > What do you think? Where we should focus our efforts performance wise????
>
> A faster XPath implementation would be great. An alternate non-DOM based
> implementation is also very interesting.
>
> > And that's not all, jsr 105, the neglected encrypted part, xkms....
> > New transformations, c14ns, j2me, etc... But that's a discussion, for
> > other thread.
>
> I have put the JSR 105 code on a branch off of the main and would like
> to integrate this for the next release. In a prior thread, people seemed
> very interested in this as it would give them a standard Java API for
> generating and validating signatures. Of course, the old API would still
> be included so you could move to it at your own pace. Let me know if you
> have any comments on this plan.
>
> Thanks,
> Sean
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: xmlsec 1.3 released... and now what's left.
Posted by Sean Mullan <Se...@Sun.COM>.
Raul Benito wrote:
> Hello Everybody,
> After the painful release of the xmlsec(mainly because of the
> updating of the web page, and deadlines in my "day" job), I begin to
> wonder where the java xml sec should lead.
>
> From my area of expertise, performance:
> The fast path (URI selection, only enveloping transformation) is as
> fast as it can gets(about 10% overhead of plain serialization and
> digesting), it can only get better with JCE(70% of execution time)
> speed ups (Juice any one??)
>
> Anyhow perhaps is time to improve performance in the slow(xpath
> transformation) path. with a little help we can get rid off the slow
> circunventbug call.
> Or perhaps is better to pursue newer fields, I having playing with
> SAX and the results are impressive, documents that the DOM library can
> not ever dream manage the SAX handles without any memory adjustments,
> and fast as hell.
> But SAX is not the api of mode anymore perhaps is better to take a
> look Stax and begin to work on it. It seems that are more projects
> using Stax than sax nowadays (axis, xmlbeans,...).
>
> What do you think? Where we should focus our efforts performance wise????
A faster XPath implementation would be great. An alternate non-DOM based
implementation is also very interesting.
> And that's not all, jsr 105, the neglected encrypted part, xkms....
> New transformations, c14ns, j2me, etc... But that's a discussion, for
> other thread.
I have put the JSR 105 code on a branch off of the main and would like
to integrate this for the next release. In a prior thread, people seemed
very interested in this as it would give them a standard Java API for
generating and validating signatures. Of course, the old API would still
be included so you could move to it at your own pace. Let me know if you
have any comments on this plan.
Thanks,
Sean
Re: xmlsec 1.3 released... and now what's left.
Posted by Raul Benito <ra...@apache.org>.
On 11/27/05, Werner Dittmann <We...@t-online.de> wrote:
> Raul,
>
> thanks for the info. If I understood you correctly then the
> performance problem is due to some specific Xpath/namespace
> usage for xml-sec, not a generic XPath problem to locate
> some elements in a document.
>
You are right, anyhow is usally slower to use xpath to select elements
than using an Id, but the xml sec should only be a little slower
because of this not a big slower as it is now.
> Background to this question:
> some specifications (WS-SecurityPolicy)
> use XPath to locate the elements to process (sign, encrypt).
>
> In case a SecurityPolicy defines a XPath I would use the XPath
> to locate the element, insert a wsu:Id and use this id to add
> the element to sign (as already done in WSS4J) thus avoiding any
> XPath processing during signature
>
> Any ideas to that, caveats to look at?
>
That sounds good to me.
But anyhow if there are more clients that need xpath, I can improve
the performance of the slow path.
And that is the main reoson for the beginig mail. To know what other
people needs. So please, if you need a faster xpath in your
signatures, raise your hands....
Regards,
Raul
> Regards,
> Werner
>
> Raul Benito wrote:
> > On 11/25/05, Werner Dittmann <We...@t-online.de> wrote:
> >
> >>Raul,
> >>
> >>first of all thanks for the big imporvments you did for xmlsec !!
> >>
> >>With respect to performance: I'm just working on JuiCE to have
> >>a JCE compliant provider for the main functions of OpenSSL. First
> >>tests I did (using some modes inside BouncyCastle) were promising.
> >>We're waiting for some Sun action (Certificate to produce a signed
> >>JCE jar).
> >>
> >
> > That will be good,
> > Juice was the reason I'll begin to hack xml-sec: at 1.0.D2 times I
> > thought the xml-sec problems was due slownes in JCE, but after seeing
> > that juice speeds a lot digesting and signing but none xml-sec i begin
> > to investigate inside xml-sec...
> >
> > I'll think that today it will speed xml-sec a lot.(well I have
> > published some figures before with xmlbench).
> >
> >
> >>Just a question about YPath: AFAIK XPath is implemented
> >>in Xalan, what is the problem regarding performance here? Or is
> >>this a problem of xmlsec using XPath?
> >>
> >
> > The root of all problems can be traced to this infamous bug in xalan:
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=2650
> > In order to not be hit with this bug in xml-sec, when it c14ns any
> > nodeset the XMLUtils.circumventBug2650 function is called. This method
> > just visit all the nodes an copy/creates all the namespace bindings
> > (the xmlns:*=... things), that contain all its ancestors.
> > I'm sure you can see that this function is a very costly operatin
> > both in time and memory(creating a lot attributtes of a DOM tree is
> > not cheap). But it also increase further processing time (the c14n is
> > mainly o(n) where n is the number of nodes that we have just manage to
> > increase, in sometimes duplicate).
> > So the xpath cannot handle big documents as it will make it bigger,
> > in an exponential way( the bigger the number elements, the bigger of
> > creation of new xmlns bindings).
> > The main difference between 1.1 and 1.2 is the splitting of the slow
> > path(the xpath) and the fast path(no xpath), and not use the
> > XMLUtils.circumventBug2650 in the fast path. And you all can see that
> > it pays off.
> > The ironic of this problem is that the XMLUtils.circumventBug2650 is
> > only seldom needed in the xpath(only when the xpath expression
> > contains any namespace selection), so in theory we can check if
> > XMLUtils.circumventBug2650 is needed and only in the small cases call
> > it.
> > But xml-sec nodeset c14n methods algorithm impose that its input has
> > been "circumvented", and it does not work with no circumvented
> > nodesets. This behaviour can be fixed (two weeks fully dedicated) but
> > we are going to end with three c14n methods:
> > - one for whole nodes.
> > - one for NOT circumvented nodesets.
> > - one for circumvented nodesets.
> > The first two will be simillar
> >
> > All in All: the xpath path in xml-sec takes a hit becouse a bug in
> > xalan, but this hit is avoidable with some work(three months of work
> > with my current "free" time).
> >
> > I hope this email is readable enough. ;)
> >
> > Regards,
> >
> > Raul
> >
> >>Regards,
> >>Werner
> >>
> >>PS: something that needs some "brush up" is the XMLCipher code,
> >>
> >
> > You are right. So many things, so few time...
> >
> >>Werner
> >>
> >>Raul Benito wrote:
> >>
> >>>Hello Everybody,
> >>> After the painful release of the xmlsec(mainly because of the
> >>>updating of the web page, and deadlines in my "day" job), I begin to
> >>>wonder where the java xml sec should lead.
> >>>
> >>>>From my area of expertise, performance:
> >>> The fast path (URI selection, only enveloping transformation) is as
> >>>fast as it can gets(about 10% overhead of plain serialization and
> >>>digesting), it can only get better with JCE(70% of execution time)
> >>>speed ups (Juice any one??).
> >>> Anyhow perhaps is time to improve performance in the slow(xpath
> >>>transformation) path. with a little help we can get rid off the slow
> >>>circunventbug call.
> >>> Or perhaps is better to pursue newer fields, I having playing with
> >>>SAX and the results are impressive, documents that the DOM library can
> >>>not ever dream manage the SAX handles without any memory adjustments,
> >>>and fast as hell.
> >>> But SAX is not the api of mode anymore perhaps is better to take a
> >>>look Stax and begin to work on it. It seems that are more projects
> >>>using Stax than sax nowadays (axis, xmlbeans,...).
> >>>
> >>>What do you think? Where we should focus our efforts performance wise????
> >>>
> >>>
> >>>And that's not all, jsr 105, the neglected encrypted part, xkms....
> >>>New transformations, c14ns, j2me, etc... But that's a discussion, for
> >>>other thread.
> >>>
> >>>Regards,
> >>>
> >>>Raul
> >>>--
> >>>http://r-bg.com
> >>>
> >>
> >>
> >
> >
> > --
> > http://r-bg.com
> >
>
>
--
http://r-bg.com
Re: xmlsec 1.3 released... and now what's left.
Posted by Werner Dittmann <We...@t-online.de>.
Raul,
thanks for the info. If I understood you correctly then the
performance problem is due to some specific Xpath/namespace
usage for xml-sec, not a generic XPath problem to locate
some elements in a document.
Background to this question:
some specifications (WS-SecurityPolicy)
use XPath to locate the elements to process (sign, encrypt).
In case a SecurityPolicy defines a XPath I would use the XPath
to locate the element, insert a wsu:Id and use this id to add
the element to sign (as already done in WSS4J) thus avoiding any
XPath processing during signature
Any ideas to that, caveats to look at?
Regards,
Werner
Raul Benito wrote:
> On 11/25/05, Werner Dittmann <We...@t-online.de> wrote:
>
>>Raul,
>>
>>first of all thanks for the big imporvments you did for xmlsec !!
>>
>>With respect to performance: I'm just working on JuiCE to have
>>a JCE compliant provider for the main functions of OpenSSL. First
>>tests I did (using some modes inside BouncyCastle) were promising.
>>We're waiting for some Sun action (Certificate to produce a signed
>>JCE jar).
>>
>
> That will be good,
> Juice was the reason I'll begin to hack xml-sec: at 1.0.D2 times I
> thought the xml-sec problems was due slownes in JCE, but after seeing
> that juice speeds a lot digesting and signing but none xml-sec i begin
> to investigate inside xml-sec...
>
> I'll think that today it will speed xml-sec a lot.(well I have
> published some figures before with xmlbench).
>
>
>>Just a question about YPath: AFAIK XPath is implemented
>>in Xalan, what is the problem regarding performance here? Or is
>>this a problem of xmlsec using XPath?
>>
>
> The root of all problems can be traced to this infamous bug in xalan:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=2650
> In order to not be hit with this bug in xml-sec, when it c14ns any
> nodeset the XMLUtils.circumventBug2650 function is called. This method
> just visit all the nodes an copy/creates all the namespace bindings
> (the xmlns:*=... things), that contain all its ancestors.
> I'm sure you can see that this function is a very costly operatin
> both in time and memory(creating a lot attributtes of a DOM tree is
> not cheap). But it also increase further processing time (the c14n is
> mainly o(n) where n is the number of nodes that we have just manage to
> increase, in sometimes duplicate).
> So the xpath cannot handle big documents as it will make it bigger,
> in an exponential way( the bigger the number elements, the bigger of
> creation of new xmlns bindings).
> The main difference between 1.1 and 1.2 is the splitting of the slow
> path(the xpath) and the fast path(no xpath), and not use the
> XMLUtils.circumventBug2650 in the fast path. And you all can see that
> it pays off.
> The ironic of this problem is that the XMLUtils.circumventBug2650 is
> only seldom needed in the xpath(only when the xpath expression
> contains any namespace selection), so in theory we can check if
> XMLUtils.circumventBug2650 is needed and only in the small cases call
> it.
> But xml-sec nodeset c14n methods algorithm impose that its input has
> been "circumvented", and it does not work with no circumvented
> nodesets. This behaviour can be fixed (two weeks fully dedicated) but
> we are going to end with three c14n methods:
> - one for whole nodes.
> - one for NOT circumvented nodesets.
> - one for circumvented nodesets.
> The first two will be simillar
>
> All in All: the xpath path in xml-sec takes a hit becouse a bug in
> xalan, but this hit is avoidable with some work(three months of work
> with my current "free" time).
>
> I hope this email is readable enough. ;)
>
> Regards,
>
> Raul
>
>>Regards,
>>Werner
>>
>>PS: something that needs some "brush up" is the XMLCipher code,
>>
>
> You are right. So many things, so few time...
>
>>Werner
>>
>>Raul Benito wrote:
>>
>>>Hello Everybody,
>>> After the painful release of the xmlsec(mainly because of the
>>>updating of the web page, and deadlines in my "day" job), I begin to
>>>wonder where the java xml sec should lead.
>>>
>>>>>From my area of expertise, performance:
>>> The fast path (URI selection, only enveloping transformation) is as
>>>fast as it can gets(about 10% overhead of plain serialization and
>>>digesting), it can only get better with JCE(70% of execution time)
>>>speed ups (Juice any one??).
>>> Anyhow perhaps is time to improve performance in the slow(xpath
>>>transformation) path. with a little help we can get rid off the slow
>>>circunventbug call.
>>> Or perhaps is better to pursue newer fields, I having playing with
>>>SAX and the results are impressive, documents that the DOM library can
>>>not ever dream manage the SAX handles without any memory adjustments,
>>>and fast as hell.
>>> But SAX is not the api of mode anymore perhaps is better to take a
>>>look Stax and begin to work on it. It seems that are more projects
>>>using Stax than sax nowadays (axis, xmlbeans,...).
>>>
>>>What do you think? Where we should focus our efforts performance wise????
>>>
>>>
>>>And that's not all, jsr 105, the neglected encrypted part, xkms....
>>>New transformations, c14ns, j2me, etc... But that's a discussion, for
>>>other thread.
>>>
>>>Regards,
>>>
>>>Raul
>>>--
>>>http://r-bg.com
>>>
>>
>>
>
>
> --
> http://r-bg.com
>
Re: xmlsec 1.3 released... and now what's left.
Posted by Raul Benito <ra...@apache.org>.
On 11/25/05, Werner Dittmann <We...@t-online.de> wrote:
> Raul,
>
> first of all thanks for the big imporvments you did for xmlsec !!
>
> With respect to performance: I'm just working on JuiCE to have
> a JCE compliant provider for the main functions of OpenSSL. First
> tests I did (using some modes inside BouncyCastle) were promising.
> We're waiting for some Sun action (Certificate to produce a signed
> JCE jar).
>
That will be good,
Juice was the reason I'll begin to hack xml-sec: at 1.0.D2 times I
thought the xml-sec problems was due slownes in JCE, but after seeing
that juice speeds a lot digesting and signing but none xml-sec i begin
to investigate inside xml-sec...
I'll think that today it will speed xml-sec a lot.(well I have
published some figures before with xmlbench).
> Just a question about YPath: AFAIK XPath is implemented
> in Xalan, what is the problem regarding performance here? Or is
> this a problem of xmlsec using XPath?
>
The root of all problems can be traced to this infamous bug in xalan:
http://issues.apache.org/bugzilla/show_bug.cgi?id=2650
In order to not be hit with this bug in xml-sec, when it c14ns any
nodeset the XMLUtils.circumventBug2650 function is called. This method
just visit all the nodes an copy/creates all the namespace bindings
(the xmlns:*=... things), that contain all its ancestors.
I'm sure you can see that this function is a very costly operatin
both in time and memory(creating a lot attributtes of a DOM tree is
not cheap). But it also increase further processing time (the c14n is
mainly o(n) where n is the number of nodes that we have just manage to
increase, in sometimes duplicate).
So the xpath cannot handle big documents as it will make it bigger,
in an exponential way( the bigger the number elements, the bigger of
creation of new xmlns bindings).
The main difference between 1.1 and 1.2 is the splitting of the slow
path(the xpath) and the fast path(no xpath), and not use the
XMLUtils.circumventBug2650 in the fast path. And you all can see that
it pays off.
The ironic of this problem is that the XMLUtils.circumventBug2650 is
only seldom needed in the xpath(only when the xpath expression
contains any namespace selection), so in theory we can check if
XMLUtils.circumventBug2650 is needed and only in the small cases call
it.
But xml-sec nodeset c14n methods algorithm impose that its input has
been "circumvented", and it does not work with no circumvented
nodesets. This behaviour can be fixed (two weeks fully dedicated) but
we are going to end with three c14n methods:
- one for whole nodes.
- one for NOT circumvented nodesets.
- one for circumvented nodesets.
The first two will be simillar
All in All: the xpath path in xml-sec takes a hit becouse a bug in
xalan, but this hit is avoidable with some work(three months of work
with my current "free" time).
I hope this email is readable enough. ;)
Regards,
Raul
> Regards,
> Werner
>
> PS: something that needs some "brush up" is the XMLCipher code,
>
You are right. So many things, so few time...
> Werner
>
> Raul Benito wrote:
> > Hello Everybody,
> > After the painful release of the xmlsec(mainly because of the
> > updating of the web page, and deadlines in my "day" job), I begin to
> > wonder where the java xml sec should lead.
> >
> >>From my area of expertise, performance:
> > The fast path (URI selection, only enveloping transformation) is as
> > fast as it can gets(about 10% overhead of plain serialization and
> > digesting), it can only get better with JCE(70% of execution time)
> > speed ups (Juice any one??).
> > Anyhow perhaps is time to improve performance in the slow(xpath
> > transformation) path. with a little help we can get rid off the slow
> > circunventbug call.
> > Or perhaps is better to pursue newer fields, I having playing with
> > SAX and the results are impressive, documents that the DOM library can
> > not ever dream manage the SAX handles without any memory adjustments,
> > and fast as hell.
> > But SAX is not the api of mode anymore perhaps is better to take a
> > look Stax and begin to work on it. It seems that are more projects
> > using Stax than sax nowadays (axis, xmlbeans,...).
> >
> > What do you think? Where we should focus our efforts performance wise????
> >
> >
> > And that's not all, jsr 105, the neglected encrypted part, xkms....
> > New transformations, c14ns, j2me, etc... But that's a discussion, for
> > other thread.
> >
> > Regards,
> >
> > Raul
> > --
> > http://r-bg.com
> >
>
>
--
http://r-bg.com
Re: xmlsec 1.3 released... and now what's left.
Posted by Werner Dittmann <We...@t-online.de>.
Raul,
first of all thanks for the big imporvments you did for xmlsec !!
With respect to performance: I'm just working on JuiCE to have
a JCE compliant provider for the main functions of OpenSSL. First
tests I did (using some modes inside BouncyCastle) were promising.
We're waiting for some Sun action (Certificate to produce a signed
JCE jar).
Just a question about YPath: AFAIK XPath is implemented
in Xalan, what is the problem regarding performance here? Or is
this a problem of xmlsec using XPath?
Regards,
Werner
PS: something that needs some "brush up" is the XMLCipher code,
Werner
Raul Benito wrote:
> Hello Everybody,
> After the painful release of the xmlsec(mainly because of the
> updating of the web page, and deadlines in my "day" job), I begin to
> wonder where the java xml sec should lead.
>
>>>From my area of expertise, performance:
> The fast path (URI selection, only enveloping transformation) is as
> fast as it can gets(about 10% overhead of plain serialization and
> digesting), it can only get better with JCE(70% of execution time)
> speed ups (Juice any one??).
> Anyhow perhaps is time to improve performance in the slow(xpath
> transformation) path. with a little help we can get rid off the slow
> circunventbug call.
> Or perhaps is better to pursue newer fields, I having playing with
> SAX and the results are impressive, documents that the DOM library can
> not ever dream manage the SAX handles without any memory adjustments,
> and fast as hell.
> But SAX is not the api of mode anymore perhaps is better to take a
> look Stax and begin to work on it. It seems that are more projects
> using Stax than sax nowadays (axis, xmlbeans,...).
>
> What do you think? Where we should focus our efforts performance wise????
>
>
> And that's not all, jsr 105, the neglected encrypted part, xkms....
> New transformations, c14ns, j2me, etc... But that's a discussion, for
> other thread.
>
> Regards,
>
> Raul
> --
> http://r-bg.com
>