santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Johnson <e...@tibco.com>
Subject Re: Small milestone for genxdm-based port of Santuario - works with Axiom!
Date Fri, 29 Apr 2011 15:36:03 GMT
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.

Mime
View raw message