Re: What I think we should focus on now

>>I completely agree with your comments. Mainly the part about fragmenting 
>>the community ... -- I'd just like to focus on actually getting things 
>>done rather than only discussing the problems. If the core developers 
>>around Jim get communicated that forward compatibility tools are what 
>>we'd like to see, they can focus on that.

>>I understand the mission of this list as to define what migration tools 
>>(and concepts) we need, so that the developers can work on them.

> I'm afraid it's not that simple.  What gets coded is what the
> developers, core or otherwise, are interested in developing.  To
> some extent this is informed by "need" as articulated in a plan for
> a complete product, but a "wish list" by itself is not going to be
> enough.  There's always more to do than there are people/time to
> do it.

> Migration tools and back porting are not yet on anybody's radar
> screen...no, they are definately on the radar screen, they are just
> off there in the distance.  The itches that need scratched right
> now are completing out what is needed to get real applications (that
> certain core developers are actually working on, ex: SteveA) running
> inside Zope3.  Once we have a Zope3 product or two for which someone
> then says, "gee, I want to run this on my existing wiz-bang Zope2
> site", *then* backward compatability will get worked on by core
> developers, IMO.  Nearer term, a Zope2 developer can decide they
> want to write some new product they need in a forward compatabile
> way.  If they then approach the Z3 developers with specific questions
> and problems, again the compatability pieces will get worked on.

Well, isn't that what I am saying? Of course it is quite early for 
getting developers to work on migration tools and backward 
compatibility. But forward compatibility, as I understand it, will be 
much easier to achieve. It is mainly a question of the right 
documentation. From what I already understand in the Zope 3 component 
architecture, it is very easy to make pure non-Zopeish Python modules 
work with Zope 3. So if somebody writes a Zope 2 product (let's say a 
database adapter) in the Zope 3 way and wraps the Zope 2 part around it 
(adding implicit acquisition and the like), it will run more or less 
unchanged for Zope 3.

Of course there might be things that are so different to achieve in Zope 
2 than in Zope 3 that this approach might not work. But even then it 
might be easier to write the code in a Zope 3 style first and then 
backport it to Zope 2, adding the pieces that are missing.

> A real, *concrete* problem is what is needed to get this process
> kick started, not a discussion of what tools we *think* we might want.

Yes. I think the best way of doing this is working on something like a 
(next-generation) CMS for Zope 2/3 ...

> (Keep in mind that I'm on the fringes of z3 development myself as
> I don't have as much time as I'd like to work on code for it.
> So my perception could be off base.  Hopefully other developers
> will correct me if I'm wrong.  And hopefully I'll start work on
> my own hybrid Zope2/Zope3 application sometime in the next
> month, and will get a lot more active.)

I'll try to do the same.

> So *I* think this list is about developing techniques and (non-software)
> tools to *manage the migration process*.  Code tools are in scope
> for discussion, but not the primary focus, IMO.

Well said. Code tools are for later. For me, the primary focus is 
getting forward-compatibility ASAP.

This might mean that some (limited) backporting is needed (like getting 
ZPT to work with the Zope 3 syntax), but I don't expect that to be a 
major issue.

Joachim


-- 

iuveno AG

Joachim Werner

_________________

Wittelsbacherstr. 23b
90475 Nürnberg

[email protected]
www.iuveno.de

Tel.: +49 (0) 911/ 9 88 39 84