Re: [Zope-dev] Consensus on the ZMI and zope.app.* namespace. (Was: SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3)

2009-02-25 Thread Martijn Faassen
Hey,

Dan Korostelev wrote:
 2009/2/25 Martijn Faassen faas...@startifact.com:
 I hope in fact zope.app.* will soon become a dumping ground for
 deprecated packages providing legacy ZMI support. Of course that will
 need the consensus that the ZMI *is* legacy software. I think do we
 already have a consensus that packages that provide other useful
 functionality shouldn't be providing ZMI support within the same
 package.
 
 Though it's a very big +1 from me that packages providing useful
 functionality shouldn't contain ZMI-related stuff within the same
 package, and that's our goal, 

Good :)

 I wouldn't say that ZMI is a legacy
 software, as it's very useful out of box and can be easily extended to
 make real use of Zope. I'd rather say that ZMI is an example of
 extensible application built on top of zope frameworks and it should
 be positioned like that.

I spoke a bit too quickly about this, then. If there are people 
interested in maintaining the ZMI then it should certainly be 
maintained. I'd see that as a project that's not part of the Zope 
Framework project but part of the Zope 3 app server project (or possibly 
a project by itself).

 BTW, I have a thought about an additional refactoring strategy: we
 could move ZMI-related packages to separate packages, like zmi.* or
 something, leaving imports in zope.app.* and making zope.app.* really
 deprecated. That way we can state that ZMI is not the Zope, but
 something built on it. And this way gives us more refactoring freedom
 :)

If people want to do this I would be fine with it. I won't focus my own 
refactoring efforts on this though as I think factoring out the 
framework functionality has a higher priority, and I have far less use 
for the ZMI. I do agree it would make it a lot more clear what the ZMI 
is about if it were in its own set of packages, and would also be a 
better kind of example.

It's not necessary to have a zmi packages for each package now in 
zope.app.*; several packages could be combined in some cases, I suspect. 
If later on for flexibility it turns out that it would be good to 
separate bits out again, this extraction can be done then. Anyway, 
whatever is the easiest way to go forward.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Consensus on the ZMI and zope.app.* namespace. (Was: SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3)

2009-02-24 Thread Dan Korostelev
2009/2/25 Martijn Faassen faas...@startifact.com:

 I hope in fact zope.app.* will soon become a dumping ground for
 deprecated packages providing legacy ZMI support. Of course that will
 need the consensus that the ZMI *is* legacy software. I think do we
 already have a consensus that packages that provide other useful
 functionality shouldn't be providing ZMI support within the same
 package.

Though it's a very big +1 from me that packages providing useful
functionality shouldn't contain ZMI-related stuff within the same
package, and that's our goal, I wouldn't say that ZMI is a legacy
software, as it's very useful out of box and can be easily extended to
make real use of Zope. I'd rather say that ZMI is an example of
extensible application built on top of zope frameworks and it should
be positioned like that.

BTW, I have a thought about an additional refactoring strategy: we
could move ZMI-related packages to separate packages, like zmi.* or
something, leaving imports in zope.app.* and making zope.app.* really
deprecated. That way we can state that ZMI is not the Zope, but
something built on it. And this way gives us more refactoring freedom
:)

Any thoughts?

-- 
WBR, Dan Korostelev
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )