As I've mentioned before on this list, I've done a port of the Santuario
Java project to work with the GenXDM library.
The port works, but now I've got an annoying problem - I don't wish to
maintain such a large fork forever. Barring the unlikely immediate
uptake of the GenXDM port in the Santuario project itself, I do
fortunately have a middle ground I can tackle - I've identified changes
that I've made in my port that make sense for Santuario with or without
the "GenXDM" aspects of my port. The changes I have in mind will reduce
the size of my port, and also I think improve the quality of the
existing code base.
For example, Santuario has code (in DOMKeyName) that looks like the
following:
public void marshal(Node parent, String dsPrefix, DOMCryptoContext
context)
throws MarshalException
{
Document ownerDoc = DOMUtils.getOwnerDocument(parent);
// prepend namespace prefix, if necessary
Element knElem = DOMUtils.createElement(ownerDoc, "KeyName",
XMLSignature.XMLNS,
dsPrefix);
knElem.appendChild(ownerDoc.createTextNode(name));
parent.appendChild(knElem);
}
Backporting my changes to the official project, this turns into this:
public static void marshal(XmlWriter xwriter, KeyName keyName,
String dsPrefix)
throws MarshalException
{
xwriter.writeTextElement(dsPrefix, "KeyName",
XMLSignature.XMLNS, keyName.getName());
}
This seems to me like a pretty unequivocal improvement to the code. This
change better conveys the intent of the code, decouples the marshalling
logic from Santuario specific object and ties it instead to standard
javax.xml.crypto interfaces, and importantly for the port that I'm
maintaining, hides the "DOM" aspects found throughout the current
version of the method.
The proposed changes avoid adding or removing any functionality, because
a goal of the GenXDM has been slavish compatibility to the existing code
base. For example, I've gone through some trouble even to match up and
eliminate changes in white space in my port. All my changes also
preserve API compatibility, as I've aimed to preserve the existing test
cases without modification. Thus these changes might be considered low
priority to the team. However, I wouldn't be proposing them unless I
thought them of real value for improving the existing code.
As I said, I'm interested in making these contributions, but I'd like to
understand from the existing contributors the best way to go about
contributing my proposed changes.
Should I open a bug report for each type of contribution, and attach my
patches to those bug reports? Or should I first submit patches to the
mailing list for discussion? What's your preferred way of working?
Should I generate a patch relative to the current trunk code, or
relative to the tag of the latest release (1.5.2) in Subversion?
Any advice and direction you can provide would help greatly.
-Eric Johnson.
