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 >
