-----BEGIN PGP SIGNED MESSAGE-----
> Hi Tres!
> Tres Seaver wrote:
>> I'll note that my original architecture document contemplated two
>> kinds of "add-on" profiles:
>> - ExtensionProfiles could register *new* kinds of steps, as well as
>> making non-destructive insertions to the configuration created by a
>> baseline profile.
>> - DeltaProfiles essentially captured line-level diffs to a "baseline"
>> I think there is room for both, where we get away from the need to make
>> EPs the "current" profile in order to use them. DeltaProfiles could be
>> "applied" by patching a snapshot, and then installing the snapshot as a
>> new baseline.
>> Because not all the files being patched are XML, I don't think we can or
>> should rely on XSLT: diff might be enough.
> I don't know if we have the resources to implement XSLT diffs and of
> course XSLT makes only sense for XML (we can still use diff for other
> files). But for XML XSLT has big advantages over normal diffs:
> - normal diffs for XML files are often very hard to read and edit
Any diff is hard to edit, so much so that I never do more than delete
entire unwanted regions. The problem of using diff against XML is only
mitigated by the fact that we go to a fair amount of trouble to generate
the XML files in such a way as to minimize the diffs.
I would be OK with some kind of optional dependency on something like
ElementTree for applying XSLT-based changes. I am *not* OK with having
to maintain any such transforms myself.
> - small changes in the XML file often make it impossible to apply a
> normal diff
Hand-editing profile XML files is tricky, anyway, at least for the ones
stored in version control. I always do a round-trip after the edit to
canonicalize the XML in the profile.
> So the use cases for these DeltaProfiles are very limited. Using XSLT
> would allow us to unify DeltaProfiles and ExtensionProfiles, providing
> an automated way for creating ExtensionProfiles.
The major use case for "deltas" (no matter whether they do XSLT
transforms or apply patches) is to permit re-applying local changes
after an upgrade. They aren't likely to be satisfactory as a mode for
distributing add-ons, I think.
I would definitely like to break the requirement that extensions have to
displace (even temporarily) the tool's import profile. I would also
like to work out how we might safely revert the application of an
extension, as well as tracking dependencies among them. I am *not*
sanguine about using XSLT as the primary mechanism for describing an
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v18.104.22.168 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests