[Zope3-dev] Re: The vision thing

[Max M]

Jean-Marc Orliaguet wrote:
> Max M wrote:
> 
>> Geoff Davis wrote:
>>
>>> Jeff Shell has posted some thought-provoking pieces on his blog that are
>>> relevant to Jim's recent attempt to better articulate a vision for Zope:
>>>
>>> http://griddlenoise.blogspot.com/2006/03/zope-crisis-of-faith-coming-this-march.html 
>>> http://griddlenoise.blogspot.com/2006/03/crisis-of-faith-messengers-have-been.html 
>>>
>> Griddle *Noise* and thats exactly what it is... noise.
>>
>> He is probably following the discussions on the lists, and then he is 
>> publishing his view on them on his blog instead of participating in 
>> the dicsussion.
>>
> That's unfair. Jeff is actively participating on the list. Which list 
> are you refering to, BTW? He has posted about 10 mails on the "two 
> visions" thread in the past 2 days.

ok. My mistake. I was judging him purely from the point of those two 
blog items, and they where rather poor imho.

Eg. "I’ve also been advocating a “Zope without all of Zope” release." 
vs. "I still have a hard time knowing how best to start a new 
‘application’ in Zope 2 or 3. There are too many options, with too much 
work to go along with each one."

Well it's simply not possible to have both more freedom of modules you 
want to use, and to lessen the options and the work needed to be done.

We will need most of the same features in the end, so either we use the 
same framwork, which will be frustrating, or we will write our own. 
Which will suck. It's not a Zope problem. Its just a fact of life. In 
any software project.


Another comment is "Gripe 1, Message message message. There is no 
message." eg. Zope sites sucks, Ruby On Rails site is great.

Well as far as I can see, the RoR people are just doing a rigged 
demonstration of what it does best. And they are still years behind in 
development of their framework.

Switching to rail will make Rail-like applications simple, but the rest 
will be very hard.

Zope on the other hands does a million things, and has been through a 
million iterations. And the websites reflects that complexity.


We coul use a better intro site I agree, and better docs, and ... yeah 
well the works. But we also have to budget our time.


>> He is just another developer who wants Zope to consists of only those 
>> elements that he is insterrested in.
> 
> but that's a perfectly valid concern. Zope needs some more decoupling of 
> its components.

Well ok. I might have been too harsh. No harm intended.

But the message I got from the blog items where that Zope sucked because 
  it didn't do it's decoupling of concerns that he wanted, the way he 
wants it.

I found *that* to be unfair, which is why I jumped the gun.

Zope 2 + 3 has a pretty clear direction. "Zope 3 is great we need to use 
it more". "Zope 2 is great we need keep it and make it use more of Zope 3".

That is the vision. We are just arguing on how to get there in the most 
efficient way. So we know we want to get from a to b. Now we are just 
arguing about the best route.


Some wants to have a big lump of connected code. Eg me. And others wants 
  a scattered collection of independent modules. But as it seems right 
now, we will probably get both.


As far as I can tell the concencus that is building is a three level 
approach:

1) a python level. With no interdependecies.

2) an appserver level. With a minimal Zope

3) an application, with z3ecm, or the like.
    (Which I find is the most important to get working)


The discussions right now are more on the line of where to draw the 
lines between the layers.


So that should be enough sepearation of concerns. And if the releases 
are in synch every 6 months, even I should be happy about that approach.


-- 

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science