[Zope3-Users] Visionaire! (All your problems, solved)

[Chris McDonough]

I think packaging efforts are really the key to being able to tell a  
story like this.  The efforts happen to be couched in a process of  
converting z3 packages into eggs, but really the process of  
identifying dependencies and eliminating the silly ones is the  
valuable work here, and it seems to be getting done by embracing egg  
packaging, which is really wonderful.  One we have well-factored  
modules that are packaged and maintained independently, all sorts of  
things like the "AS" vs. "CA" you mention or a Zope 3 core that is  
more like "zope.bobo", or a Zope that combines both z3 and z2 in  
various ways becomes a lot more possible.

On Mar 1, 2006, at 7:42 PM, Jeff Shell wrote:

> We've been through a lot lately. You know it, I know it. Zope has a
> reputation. Sometimes it's good, sometimes it's bad. This has affected
> Zope 3, since Zope 3 is very much "not Zope 2". But it's affecting
> Zope 2 as well, as Jim has brought to our attention. Zope 3 is Mature.
> Zope 3 sounds like Zope 2+1. Zope 2 and Zope 3 have very different
> concepts. Zope 3 has restricted its audience, for now, to developers;
> while Zope 2 is appealing to many different kinds of end users and
> programmer types. Five offers a bridge so that Zope 3 as a library may
> be used in Zope 2, and the Zope 2 core has started making use of some
> Zope 3 concepts.
>
> But it's obvious we have a name problem. Even within Zope 3, there's a
> name problem, between "Zope 3 as Application Server" and "Zope 3 as
> cool collection of packages".
>
> Today, I wrote a much longer message in response to the "Two Visions"
> thread. But I was in a bit of a bad mood, having spent many hours
> trying to set up a test harness to test one little thing in my own
> code that was causing problems - a "one little thing" that depended on
> quite a few components being set up, and it was painful. And I'm still
> not done. And I realized, as I stewed away, that I like Zope 3 as an
> Application Server... But I'd like it with less. And this option
> hasn't been proffered, so far as I can tell. It seems like Jim's
> Vision might be two options - "zope as library" and "big zope
> application server with all of the object file system and probably
> through the web stuff and so on and so on and would be largely
> compatible with both Zope 2 and Zope 3 as they stand today."
>
> Personally, I'd love to have the first option. I also, personally,
> don't care if I have the second option, but I recognize the need or
> desire for it, and the desire to get out the message that Zope 2 and
> the applications on it actually do have a future even though they may
> not have a future with Zope 3 as Zope 3 is currently known.
>
> I'd like a third option: the Zope 3 Application Server as it is right
> now, but with less. No Rotterdam skin, perhaps no ZMI. No content
> objects at all, except maybe for some example file and image objects
> to show how to do BLOBs. It would still be ZODB based. It would still
> be ILocation based. zope.app.container would be prominent, and
> zope.app.folder would not be a distraction. It's the basis for
> building applications like Schoolbell/Schooltool, custom content
> management, itinerary managers, knowledge bases, whatever. Catalog,
> local sites/utilities, all still there. But without the distraction of
> "should I support the ZMI? use it as my user interface?" "should I use
> the TTW page templates?". "IFolder and IContainer... What is the
> difference and which should I use? Which should be my base class"
> (because at Bottlerocket, we chose Folder when we shouldn't have, we
> found out much later). Maybe that stuff would still be in the library.
> Maybe it would still be available as a 'mkzopeinstance' option. But
> the Zope 3 Application Server would probably work best if it promoted
> custom development via persistent objects, views, and custom skins, as
> the default way of working with it. It's easier to write documentation
> for, it could be easy to write mkzopeinstance commands for (to
> generate a basic starting point with skeleton code and a site.zcml
> setup that loads the custom skin). There's not this other User
> Interface and other objects providing a distraction. "I'm making a
> wiki. How does SQL Script apply? I18N File?".
>
> And then I thought about Taligent, for some reason. I'm not going into
> the history of the company/project, whose products never really made
> it out into the light of day. But at some point, they broke their
> product (which was to be a new "object oriented operating system") out
> into a small set of distinct offerings: TalOS (Taligent Object
> Services), TalAE (Taligent Application Environment), and so on. And I
> thought about doing this for Zope, and came up with the following:
>
> - Zope 3 CA: The Zope Component Architecture. Core services. Would
>   include zope.publisher and most other current top level zope.*  
> things.
>   Usable as a library, as a publisher for other environments,  
> perhaps as a
>   simple standalone server. Easy to deploy against WSGI, Paste.deploy,
>   whatever.
>
> - Zope 3 AS: The Zope 3 Application Server. A Zope 3 CA stack using  
> the
>   ZODB, ILocation, and most of the zope.app services but without  
> any content
>   objects. Perhaps only an application server configuration skin  
> (process
>   management) but no ZMI. Maybe have the current configuration  
> installable as
>   an option.
>
> - Zope Suite (or Zope Web or Zope DE): This is the full  
> "application server"
>   perhaps Jim is envisioning. A comprehensive web based user  
> interface, based
>   on features (and implementations) of both Zope 2 and Zope 3  
> application
>   servers and offerings.
>
> We don't need a hundred different "editions" like Microsoft. Nor do we
> need a hundred different acronyms like Java development seems to have.
> I think we could boil things down to these three offerings, while
> sticking with the current timed release plan as well. And it would
> finally make a useful and usable "Zope Without Zope" downloadable
> option available as Zope 3 CA.
>
> I can envision the web site now, and may mock a simple and sexy text
> based one up later this evening. We could even get it up now
> (zopesuite.org anybody?).
>
> - Zope 3 CA: Provides the core elements and concepts for building and
>   sustaining loosely coupled Python programs, as well as the  
> fundamental
>   object publishing toolkit that's been powering Zope based web sites
>   since 1996 (1995?). [download now | more information]
>
> - Zope 3 AS: The Zope 3 Application Server. A new approach to Zope  
> web sites
>   built entirely on the Zope 3 Component Architecture and Zope Object
>   Database. A full stack for developing custom web sites and  
> applications
>   using only Python and your imagination. [download Zope 3.2 now |  
> more info ]
>
> - Zope Suite: Built on Zope 2 and leveraging elements of the Zope 3  
> CA and
>   Zope 3 AS, the Zope Suite provides a robust and mature web  
> development
>   environment that is in place already behind many web sites and  
> applications
>   worldwide. [download zope 2.9 now | more info | roadmap ]
>
> Thoughts?
>
> I think this keeps Zope 3 as we know it alive, keeps the Zope brand
> intact, and offers a future for Zope 2 and similar caliber desires for
> a Big App Server while not interfering with the more "pure" and simple
> concepts that makes Zope 3 appealing for developers like me.
>
> --
> Jeff Shell
> _______________________________________________
> Zope3-users mailing list
> Zope3-users at zope.org
> http://mail.zope.org/mailman/listinfo/zope3-users
>