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

[Martin Aspeli]

On Thu, 02 Mar 2006 00:42:14 -0000, Jeff Shell <eucci.group at gmail.com>  
wrote:

Personally, I still find it hard to know where the line goes between the  
ZMI and my own UI code, if I should be extending the ZMI or replacing it.  
Perhaps because I'm tainted by Zope 2's idea of the ZMI, though.

Personally, I think it's insane that Zope 3 still has TTW scripts and  
templates enabled by default. :-)

Personally, I think that Zope 3-the-CA would be the useful in a Zope 2  
+ Five context, at the very least, which is where a lot of interest will  
continue to come for.

Without understanding the detailed implications of your vision, I must say  
it's quite attractive. Perhaps the difference between the AS and the Suite  
may be hard to explain and keep clean, though - I'm really not sure.

But less-is-more is a good concept when it comes to frameworks like the Z3  
CA. The less stuff I have to learn and understand that's not relevant to  
me (e.g. as a Five-focused developer, or as someone with lower  
requirements) the better. Should be easier to document it in these stages,  
too... And I like having distinct names for the different parts of that  
puzzle.

Martin


> 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



-- 
(muted)