[Zope-CMF] Re: RFC: GenericSetup Architecture Proposal

[yuppie]

Hi Tres!


Tres Seaver wrote:
> yuppie wrote:
>>
>>At the first glance that makes export_steps.xml and import_steps.xml
>>obsolete. But there is the MetaProfile that has to be shipped with a
>>BaselineProfile and that is maintained in the tool. Why do we still need
>>MetaProfiles? Can't we just walk through a site/profile and
>>export/import each object that has a handler?
>>
>>http://mail.zope.org/pipermail/zope-cmf/2005-September/022877.html
>>proposes to use im- and export adapters for content objects. Can't we do
>>the same for config objects, registering the SetupHandlers as adapters?
>>And get rid of the special SetupHandler registries completely?
> 
> 
> I don't think so.  What would we be adapting here?

The configuration objects (e.g. tools). Of course we would need a way to 
create new empty objects on import before we can adapt and configure them.

> I like the fact that
> the MetaProfile represents the set of policy choices which make up a
> given "installable site configuration":  e.g., imagine Nate's
> Plone4Media as a setup profile.  Or imagine a Silva profile, or one
> which is built around "classic" Zope with PAS.  I want to be able to
> spell which handlers are in play for a given profile, to permit
> installing them independently.

Sure MetaProfiles have some benefits. It depends on our objectives if 
they are useful or not.

Here some goals that are easier to achieve without MetaProfiles:


1.) make code and profiles more reusable:

Primarily setup handlers are serializers/deserializers. There are other 
places where we could make use of them, e.g.:

- fssync based XML im- and export 
(http://mail.zope.org/pipermail/zope-dev/2004-November/024057.html)

- dav/ftp

- add forms that allow to create pre-configured objects (as they 
currently exist for type infos and workflows, but without support for 
profile data)

The current profile format looks already very similar to a fssync or 
dav/ftp checkout, representing each configuration object by an XML file. 
In the long run I'd like to see all kinds of exports converge to one format.


2.) make code and profiles more simple:

MetaProfiles and ExtensionProfiles don't play together very well. 
Instead of trying to resolve issues like those discussed in 
http://mail.zope.org/pipermail/zope-cmf/2005-June/022435.html by making 
the MetaProfile machinery more complicated, I'd prefer to get rid of it.

Profiles also become simpler if there's no need to specify handlers 
explicitly.


> BTW Yuppie, will you be in Vienna next week for the Plone conference?
> I'd enjoy chatting about this and other issues in person, if so.

I didn't make it to the Plone conference, but we'll meet at the castle 
sprint. Looking forward to seeing you.


Cheers,

	Yuppie