[Zope-CMF] Re: [dev] RFC: rethinking GenericSetup extension profiles

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

yuppie wrote:
> Hi Tres!
> 
> 
> Tres Seaver wrote:
>>
>> I'll note that my original architecture document[1] 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"
>>     profile.
>>
>> 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
extension.


Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEyNPB+gerLs4ltQ4RApfxAJ4yQNxmj4sgczUUbAr+xXsrpeemLgCeMrlj
NLIF7Qm6NYHtQVAeh36tTz8=
=1NNR
-----END PGP SIGNATURE-----