santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: xmlsec 1.3 released... and now what's left.
Date Tue, 29 Nov 2005 02:59:52 GMT
Sean,

+1 from me.

-- dims

On 11/28/05, Sean Mullan <Sean.Mullan@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/

Mime
View raw message