Hi Colm,
Thanks for the response!
On 4/28/11 7:38 AM, Colm O hEigeartaigh wrote:
Hi Eric,
Apologies for not replying to you on this earlier. Congrats on the
achievement of getting everything working with Axiom. I have a couple
of questions....
1) Have you considered using DDOM? This is more interesting to me than
non-standard APIs such as gen-xdm/AXIOM/etc.
DDOM, is of course, one path to look at. GenXDM has larger goals (it
supports the XQuery Data Model, so is a good library to work underneath
an XPath 2, XQuery, or XSLT 2.0 engine, for starters), and the port of
the XML Security library is just one step in those goals.
Having made this port work for Axiom, I'm confident we can do a bridge
for XOM, JDOM, DOM4J, and internal XML APIs, all without difficulty.
2) Are you going to create a build which is a port of the Apache XML
Security for Java 1.4.4 release? What is your release plan going
forwards in terms of tracking Santuario releases? Are you going to
pick up on the (fairly extensive) changes made on trunk? How will you
merge bug fixes to your code?
I've already tracked changes for the 1.4.4 release. Obviously, this
library being as sensitive as it is, I don't want it to fall too far
out-of-step with the official releases.
3) Have you considered whether it might be a good idea to submit this
project as a subproject of Apache Santuario?
Yes. We would consider that a wonderful outcome. However, GenXDM, at the
moment, isn't an Apache hosted project. We're trying to prove out
GenXDM's value. Mind you, we're eventually hoping to get enough interest
that GenXDM that it can make for a viable Apache project.
4) There may potentially be trademark issues with the current name of
"santuario-genxdm" - I'll have to check on this.
Although I'm not a lawyer, I've encountered enough legal concerns over
my career that I'm not particularly concerned on this point. At this
moment, the labeling is merely factual - effectively "port of Santuario
to GenXDM." Long term, either this port merges back with the official
code base, or we have to come up with a name. Of course, at least in the
US, you can always sue about anything, however baseless. So if someone
puts up a fuss, we'll happily concoct a name, but we'll still be saying
"Project _____, a port of the Santuario XML Security library to use GenXDM."
Now that I'm looking at an actual binary deliverable, the names will be
different on the JAR files.
Lastly, if you have come across any particularly inefficient code etc.
when doing the port, then I'd certainly be interested to hear about
it, as I'm doing some work in this area on the current trunk code.
Since I want to keep this port as easy to maintain as possible, I've
been making minimal changes to functionality. I found a bug in the 1.4.3
code base as a consequence of adding generic parameters everywhere. That
bug, however, was fixed in 1.4.4, so I didn't have to do anything but
port the delta.
I have considered one functional change. In canonicalization, there's a
workaround for a bug in the Xalan XPath engine. That work-around
requires modifying the input document to propagate namespace
declarations down the tree. With GenXDM, that work-around is completely
unnecessary, because that propagation is handled simply by passing a
"true" value for a boolean to the method that traverses the namespace
axis. I've been told by a colleague that that particular work-around has
a serious performance impact, so switching to GenXDM's capability might
have a benefit.
As yet, I've been much more focused on getting the functionality exactly
right, and not so much on the performance (although notably, some of the
test cases I've ported to use GenXDM run *faster* than their DOM
counterparts). So I don't have any insights on performance as yet.
-Eric.
Thanks,
Colm.
On Thu, Apr 21, 2011 at 5:49 PM, Sean Mullan<[email protected]> wrote:
On 4/20/11 1:43 PM, Eric Johnson wrote:
A quick email to note an interesting milestone that we just achieved.
For those who missed my previous emails, over at Apache Extras [1], we've
been
working on the santuario-genxdm [2] project, which is a port of the
Santuario
project to work using GenXDM [3].
With our latest release of GenXDM, we introduced support for a new
"bridge" to
the Axiom [4] data model. That meant, in theory, that the santuario-genxdm
project could now work with three different data models - Axiom, DOM, and
our
reference implementation we call "Cx".
In practice, Axiom didn't quite work. One security test case was failing.
Yesterday, we fixed that bug, so the next release of GenXDM, coupled with
santuario-genxdm, means that you can encrypt, decrypt, sign, and
canonicalize
Axiom-based tree models with full compliance.
In any case, one reason for writing this post is that it seems like we've
passed
a crucial milestone, and ought to do an "official" build of
santuario-genxdm, so
that others don't have to grab the source to build it and play with it.
The trick is, the port really should be a drop-in replacement (plus the
requisite GenXDM JARs). We've attempted to maintain full API
compatibility.
Except that actual drop-in replacement would imply keeping the same names
as the
existing JARs. Not wanting to step on any toes, or pretend this release is
something it isn't, keeping the existing xml-security JAR file names seems
like
a bad idea. What name changes should I introduce?
I agree that you should avoid using the existing xmlsec.jar name. But other
than that, I don't have any specific recommendations, and I think the name
is completely up to you.
--Sean
-Eric.
[1] https://code.google.com/a/apache-extras.org/hosting/
[2] https://code.google.com/a/apache-extras.org/p/santuario-genxdm/
[3] https://code.google.com/p/genxdm/
[4] https://ws.apache.org/axiom/
