[Zope-CMF] Re: [dev] RFC: rethinking GenericSetup extension profiles
-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 - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] RFC: rethinking GenericSetup extension profiles
On 7/26/06, yuppie <[EMAIL PROTECTED]> wrote: Even this small difference doesn't exist. The profile it is diffed from is just a normal dependency. OK. I'm trying to come up with errors in this plan, but I fail. The closest i come is that you will need to have different extension profiles for different base profiles, that is one for plain CMF, one for CPS and one for Plone. But the chance that you would actually be able to use the same extension profile for these three systems is so remote anyway, that I can't even claim that to be an actual problem. :) So, I'm +1 on this. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [dev] RFC: rethinking GenericSetup extension profiles
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 - small changes in the XML file often make it impossible to apply a normal diff 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. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] CMF Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open jens - "CachingPolicyManager: Support OFS.Cache.CacheManager", [Accepted] http://www.zope.org/Collectors/CMF/408 mhammond - "Windows DevelopmentMode penalty in CMFCore.DirectoryView", [Accepted] http://www.zope.org/Collectors/CMF/366 shh - "CMFUid: cmf_uid attribute acquired when cataloging", [Accepted] http://www.zope.org/Collectors/CMF/446 Pending / Deferred Issues - "Wrong cache association for FSObject", [Pending] http://www.zope.org/Collectors/CMF/255 - "CMFSetup: Windows exports contain CR/LF, LF and even CR newlines", [Pending] http://www.zope.org/Collectors/CMF/266 - "FSPropertiesObject.py cannot handle multiline input for lines, text attributes", [Deferred] http://www.zope.org/Collectors/CMF/271 - "Can't invalidate skin items in a RAMCacheManager", [Pending] http://www.zope.org/Collectors/CMF/343 - "CMFSetup: Workflow Tool export fails with workflows which have scripts", [Pending] http://www.zope.org/Collectors/CMF/373 - "CMFCore.Skinnable.SkinnableObjectManager can merge skin data", [Pending] http://www.zope.org/Collectors/CMF/375 - "Proxy Roles does't work for a Script using portal_catalog.searchResults", [Pending] http://www.zope.org/Collectors/CMF/380 - "workflow notify success should be after reindex", [Pending] http://www.zope.org/Collectors/CMF/389 - "'except ...: pass' in CMFCore/TypesTool.py:_queryFactoryMethod() nullifies VerboseSecurity", [Pending] http://www.zope.org/Collectors/CMF/410 - "Possible bug when using a BTreeFolder Member folder", [Pending] http://www.zope.org/Collectors/CMF/441 Pending / Deferred Features - "Favorite.py: queries and anchors in remote_url", [Pending] http://www.zope.org/Collectors/CMF/26 - "DefaultDublinCore should have Creator property", [Pending] http://www.zope.org/Collectors/CMF/61 - "Document.py: universal newlines", [Pending] http://www.zope.org/Collectors/CMF/174 - "Add condition for transition's action like other action", [Pending] http://www.zope.org/Collectors/CMF/207 - "Major action enhancement", [Pending] http://www.zope.org/Collectors/CMF/232 - "portal_type is undefined in initialization code", [Pending] http://www.zope.org/Collectors/CMF/248 - "CMFTopic Does Not Cache", [Deferred] http://www.zope.org/Collectors/CMF/295 - "Wishlist: a flag that tags the selected action.", [Pending] http://www.zope.org/Collectors/CMF/301 - "CMFDefault should make use of allowCreate()", [Pending] http://www.zope.org/Collectors/CMF/340 - "Nested Skins", [Deferred] http://www.zope.org/Collectors/CMF/377 - "CatalogVariableProvider code + tests", [Pending] http://www.zope.org/Collectors/CMF/378 - "manage_doCustomize() : minor additions", [Pending] http://www.zope.org/Collectors/CMF/382 - "CMF needs View-based TypeInformation", [Pending] http://www.zope.org/Collectors/CMF/437 - "Marker attributes should be deprecated", [Pending] http://www.zope.org/Collectors/CMF/440 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
