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