Hi Colm,
On 4/29/11 6:51 AM, Colm O hEigeartaigh wrote:
Hi Eric,
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.
1.4.5 will be going out pretty soon, so I recommend porting the
changes made for this as well. I guess this is an obvious problem with
forking code, e.g. if you were to leave that project, would the next
maintainer bother merging security fixes etc.
Yes, absolutely, I will be merging those changes. Also, I recognize that
long term, some solution needs to be found to either completely fork, or
merge back in, but maintaining an ongoing branch is quite tricky -
especially when it is of such a huge magnitude of changes!
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.
Cool! I think this would be the best outcome, to mitigate concerns
about forking the codebase I raised above. One could envisage making
the current Santuario codebase into a multi-module maven project to
accommodate both approaches, or it could stay as a separate
sub-project.
Well, my preferred outcome would be to have Santuario simply use GenXDM,
and not have a fork at all. But then, you probably guessed that.
Hmmm - does the reference to Maven mean that you're switching to Maven
for the build?
What kind of process do you envisage happening to turn GenXDM into an
Apache project? Does it really matter for the santuario-genxdm project
whether the GenXDM code is in Apache or not?
At this point, we're trying to prove the value of the GenXDM approach,
and with that, get other people interested in contributing. Once we get
a few more people interested, we'll resubmit our incubation proposal
(http://wiki.apache.org/incubator/gXMLProposal).
Having GenXDM at Apache doesn't matter for the santuario-genxdm project,
no. However, it does matter if we want to get wider adoption the
project, or eliminate the fork of XML Security, and merge the branch
back to the core code.
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.
I plan on removing Xalan altogether from the code on trunk for a 1.5.0
release. I've already removed it from all of the tests, but I haven't
gotten around to tackling some of the lower-level stuff in the source
code yet.
That shouldn't be too hard, as I recall it wasn't that hard to port the
XPath filters to use the GenXDM APIs for XPath.
-Eric.
