[Zope3-Users] Visionaire! (All your problems, solved)

[Peter Bengtsson]

I'm with Max on this one.

What's the point? To save a few megabytes of harddisk space?
If you don't want the zope.bobo part of your zope3, ignore it. You
don't have to use it if you don't want to.

It's been a while but the last time I installed Plone it came with
stuff like CookieCrumbler and Formulator. What a bliss and time-saver!
It's not "unix-right" but I don't care, I have other stuff to spend my
precious time on such as coding.

Making things simple will (and always has) be superior to making
things clinically correct in the computer industry.

You point, Jeff, was that the Zope2 ZMI is "plaguing" the true Zope3
as you know it. I'm not worried about this personally. On most of my
zope2 products the ZMI is just used as a debug tool rather than
something clients get to work in.

Sure, people have misstaken Zope for Plone when they use the windows
installer and we've all seen newbies complaining about bugs in zope on
the zope mailing list which just happens to be a 100% plone related
only.
Tough. I'd rather have a few of these lost beginners who are wrong
than no new beginners at all.

Let's keep it simple, bundle it all in one fat package and ignore the
excessive zmi files that gets thrown in.

On 3/2/06, Max M <maxm at mxm.dk> wrote:
> Jeff Shell wrote:
>
> >I think this keeps Zope 3 as we know it alive, keeps the Zope brand
> >intact, and offers a future for Zope 2 and similar caliber desires for
> >a Big App Server while not interfering with the more "pure" and simple
> >concepts that makes Zope 3 appealing for developers like me.
> >
> >
>
> I think its an absolutely terrible idea!
>
>
> The most succesfull Zope 2 "product" out there is most likely Plone. And
> it has everything and the kitchen sink in it.
>
> Python also has a lot of libraries included, which means that you
> seldomly need 3. party libraries to extend Plone.
>
>
> I fear that loosely coupled libraries does not make an app server. I can
> just imagine the upgrade hell when one package requires two different
> packages, and another package requires the same two different packages,
> but in different versions.
>
> Canonical releases of compatible package collections is a *must*.
> Splitting it all up in small chunks that are out of sync would be a
> disaster.
>
> Releases that contains a *huge* compatible collection of packages is the
> most effective way to move forward in an unified way.
>
> Plone products works together because Plone is so well defined.
> Sometimes this feels like a straightjacket. On the othe hand, in plain
> Zope 2 it is practically impossible to reuse other peoples products on
> your own site because the playing field was too loosely defined.
>
>
> But just like you don't have to learn every Python library to use
> Python, you should not have to know every package in the app server.
> That is not a question of making seperate releases though, it's the age
> old programming problem of structuring code with few interdependencies.
>
> So throw everything into the release. heck even throw Zope 2 in there if
> you have to. But dont force the programmers to use it before they need
> the functionality.
>
> --
>
> hilsen/regards Max M, Denmark
>
> http://www.mxm.dk/
> IT's Mad Science
>
> _______________________________________________
> Zope3-users mailing list
> Zope3-users at zope.org
> http://mail.zope.org/mailman/listinfo/zope3-users
>


--
Peter Bengtsson,
work www.fry-it.com
home www.peterbe.com
hobby www.issuetrackerproduct.com