Consensus on the ZMI and zope.app.* namespace. (Was: SVN: zope.app.openidconsumer/ New library for OpenID auth in Zope 3)
2009/2/25 Martijn Faassen <faassen@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
Hey, Dan Korostelev wrote:
2009/2/25 Martijn Faassen <faassen@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
participants (2)
-
Dan Korostelev -
Martijn Faassen