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

Reply via email to