-----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 [EMAIL PROTECTED] 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----- _______________________________________________ Zope-CMF maillist - [email protected] http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
