[Zope-CMF] Plone/Metadata/FUD

[Helge TEsdal]

<snip>
> I've seen a tendency these last month in the community, where people are
>  percieving Plone as an extended CMF-implementation, that people like so
>  much, that there's talk of porting Plone back into the CMF (Core or
> Default). This I belive would be a major design-error for Zope3, where I
>  belive we should keep a clean framework that can be used as a base for
> both  the PTK's and other types of products... i.e we're building
> automated  production solutions for broadcasters, and they have very
> little need for  all the stuff in Plone, just like most Plone-users
> won't have anything to  use our streaming media CMS for... it's just two
> very different worlds,  that have very different needs, but both worlds
> should build on the same  framework, without _having_ to interfer with
> eachother... so I don't see  any reason for porting anything from Plone
> back into CMF, but it would be  nice if the various parts of Plone was
> available as individual products,  that could be used as needed - on an
> opt-in basis.


If I get this right, you are afraid of CMFCore (and in time Zope3)
becoming Plone. If this is the case, you got nothing to worry about. The
CMF and Zope3 developers know what they are doing and would never try to
put Plone into the base frameworks. None of the Plone developers are
arguing that CMFCore should evolve into Plone either.

That being said, sometimes people develop components that would fit into
the framework. If features from CMFDefault, Plone, or MMManager for that
matter are considered suitable for the core framework, they can be
included. Considered suitable are the key words here. If you want
examples, the URLTool from CMFDefault and the CustomizationPolicies from
Plone might be useful in CMFCore. Deciding where to put the different
features is an ongoing process, and I believe the CMF developers are able
to make the right choices.

You have also expressed a wish for better modularization in Plone,
enabling developers to use different components more easily. This is
something the Plone team will do. It might also give a better impression
of how Plone relates to CMFCore and CMFDefault and help avoid
misunderstandings and confusion in the future.

As a final point I would like to add that there is a good dialogue between
the CMF developers and the Plone developers, and that the Plone team
certainly feel like they are contributing to improving CMF.

--
Helge