[Zope] Re: Presentations Available

[Tres Seaver]

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

Nick Davis wrote:

<snip>

>>> - Third party products that are not yet fully compatible
>>>   with Plone 2.1 and/or Zope 2.8.
> 
> Should this perhaps be the other way around? If those products used the
> APIs correctly, perhaps a new release of Zope/Plone should still support
> old APIs and/or deprecate them gradually and with warning?

Zope and CMF already adopt this practice for "public" APIS.  Some of the
incompatibilities people report come from reliance on non-public
implementation details;  others are bugs in Zope or CMF.  I don't know
what Plone's policy is about deprecating APIs / features.

> This is a difficult problem to address but sometimes it may be better
> to hold back on releasing something new if it causes things that
> depend on it to break. On the other hand I can understand peoples
> desire to release something new and cool (even if not quite ready) .
> ;-) And its hard to know quickly what the bugs are if you don't
> release it to the real world. So hard to know what to do..........
> 
>>> - Sites that have customized parts of Plone they shouldn't
>>>   have touched in the first place.
> 
> This is an important issue. It is difficult not to touch things that one
> shouldn't. A trivial example - If you want your breadcrumbs to just list
> the breadcrumbs instead of say "you are here" you have to copy across
> global_pathbar.pt and take out "you are here". There is not another easy
> way to do it that I can see. If you then migrate to 2.1, that .pt has
> changed so you have to copy the new one and re-do it otherwise nothing
> renders. If you want to add another logo on the right of the header you
> have to hack Plone's templates further. Each change is in itself trivial
> but they add up and when you migrate, you;re left with stuff that
> doesn't work and spend quite a while resolving it. And thats for those
> of us savvy enough to use the filesystem. Those who customised through
> the ZMI will have a bigger headache.

There are real tensions here, especially when dealing with UI code:

 - Maintainability is a virtue for the programmer, but often drives a
   factoring of the templates which make them useless for other
   stakeholders, such as designers.

 - Reusability is always confounded when policy and mechanism are mixed
   together:  UI is very much policy-centric, which makes reusing its
   mechanisms *very* hard.

<snip>

> My real worry is when we do have a new release of Plone sitting on top
> of Zope 3 we'll have a whole new set of bleeding edge code sitting on
> top of other bleeding edge code, while stuff that did work with a mature
> AT1.3.x (or 1.4.x or whatever) suddenly stops working.
> Hopefully this will prove to be an unjustified fear!

Zope3 itself will hardly be "bleeding edge" at that point;  the path we
are taking to get there (the "Goldegg initiative"), should make the size
of each change set more manageable.

> Probably this is no-one's fault. It is the nature of open source. To
> compare, have to admit I tried to get Bricolage to work a while back,
> and ran into CPAN dependency hell.
> 
> I wonder if perhaps the real problem is trying to do so much with so
> few resources. Linux has a very mature platform as much of its base,
> and a lot of commercial support which helps. Perl and the CPAN is
> quite mature now and also had quite a lot of commercial support. The
> good thing about commercial support is people being paid to do grunt 
> work and run loads of tests and update documents. Both Linux and CPAN
> are very modular. It is relatively easy to change one part without
> knowing about other parts. I think it would be easier to find someone
> who could patch a broken CPAN module, than someone who could delve
> inside Zope and Plone. This is because many of us don't understand
> the various components of the underlying architecture, and a lot is
> changing for Zope 3. Also many Perl modules are widely used by many
> applications, whereas a lot of Zope code is only used by other Zope
> code.

One of the major promises of Zope3 is that it makes for more modular
code, because its component architecture makes it easy and natural to
break apart monolithic classes into components related by well-defined
interfaces.


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.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDRnzC+gerLs4ltQ4RApayAJ9fvkj3rPFmM1wxl2agDOf+WFqvHwCeN7/I
4FwWQPNsmxo0Urxjq+52Q8A=
=MgUC
-----END PGP SIGNATURE-----