Martijn Faassen wrote:
>>> I think focusing on one app server and a dedicated set of libraries
>>> would be a good alternative to two concurring app servers.
>> ...if the single app server is based on acquisition, 
>> __bobo_traverse__ and friends, objectValues and friends, ZCatalog, 
>> and so on, I'd rather have two, thanks: at least I can have one I like.
> I can see where Philipp is coming from: yes, it would be good to
> collapse the Zope 2 and Zope 3 communities into one if that frees up
> more development resources and lets us do less duplicate work.
> This cannot however be done by big steps or mandate or changing names,
> and this is where I think I disagree with Philipp somewhat.

I don't think we disagree here. Like you, Martijn, I believe in evolution.

I find the idea of Zope 3 not having to catch up with Zope 2 very
appealing. We can continue to evolve Zope 2 instead. And yes, Gary, this
means we will eventually get rid of or provide alternatives to crufty
Zope 2 APIs. Zope 2.9 has already deprecated one particular Zope 2 API
(the event stuff), I expect upcoming versions to do more like that.

> We're on the right track already. The communities are merging into a
> single community. Just compare today with the situation just one year
> ago - massive changes everywhere, and positive ones.

You're absolutely right. So focusing the effort in the app server
development department seems only logical.

> I just don't understand how the current zed/Zope 5 proposals would make
> everything go faster or be easier or be clearer...

It just articulates in papal words what has been going on so far and
what might be the future for Zope 3 vs. Zope 2. Leaving aside Jim's
naming suggestion, door #2 is a clear vision for the continuation of
Zope 2 and Zope 3 in a common platform. It is nothing that is done today
or tomorrow. There no immediate speed ups in development, only long-term
ones, hopefully.

I spend a fair amount of time on Five development just to reproduce Zope
3 features in Zope 2. On the other hand, a lot of people spend a fair
amount of time on bringing Zope 2 features to Zope 3. Why couldn't these
efforts be consolidated? Will the consolidation product ("Zope 5") be
backward compatible with Zope 2.9 as we have it now? Probably not,
there's an evolution path to it. Will we be able to evolve to it? I
certainly think so.

Perhaps it has been misunderstood, but Jim's door #2 proposal doesn't
really make any technical claims nor "promises", it is just a vision to
focus efforts in certain things. It's an effort roadmap. And it is
actually very close to the lines of thinking that let you, Martijn, (and
eventually myelf) start or embrace the Five project. I see it as the
logical Zope roadmap resulting from the Five efforts. In a way we should
be happy that the Five effort showed that Zope 2 is still important but
is also willing to evolve.

By the way, I think Terry Hancock made some very good points regarding
marketing issues. However, as a "core" developer, I would tend my vision
is blurred on this particular issue :).

Zope3-dev mailing list

Reply via email to