Sean, +1 from me.
-- dims On 11/28/05, Sean Mullan <[EMAIL PROTECTED]> 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/
