On 3/1/06, Shane Hathaway <[EMAIL PROTECTED]> wrote: > Jeff Shell wrote: > > - 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. > > That's quite appealing, IMHO. Could you agree with the following > distinction? > > - Zope 3 CA expects the model (and the method of persisting the model) > to be completely defined by the Python programmer.
Yes, although Zope 3 CA could also be used in non-web environments (I've used it in an internal package manager experiment, for example). I'd like the Zope 3 CA download to include some useful examples and/or skeletons (possibly configured for Paste Deploy) to show some of the different options - use with SQLObject, other template packages (page templates would be included with the core though), etc. It could also include some other publisher/publication objects that could show integration with tools like Routes, for example. These extras would be outside of the core library, of course. For purposes of documentation and evangelizing, the Zope 3 CA can provide improved documentation about core Zope concepts like object publishing, without having to put Zope 3 AS expectations or terms on the programmer, giving them an entry point to the larger world of the Zope Application Servers without being overwhelming. Then we (or someone else) can write "Python on What Have The Romans Ever Given Us", which would show how you can do a rails "programming by convention" style system using the component architecture. The CA would automatically create adapters/views to bind ``models/person.py``, ``controllers/person.py``, and ``views/person/list.pt`` together. How those adapters are registered and used by the publisher would show off the CA. > - Zope 3 AS expects most of the model to be stored in ZODB and implement > ILocation. However, it still expects model objects to be defined by the > Python programmer. Yep. Zope 3 AS might also yield a solid foundation of base interfaces to allow easier use of 'sqlos' and/or 'sqlalchemy' backed objects that still provide a core set of useful and usable information (dublin core, etc), and could offer the option of using one of those instead of the ZODB while providing the caveat that use of other (third party) 'model' components may require additional work to map. Essentially, Zope 3 AS would be the option for those who like the Zope 3 + ZODB way. So many of these other web 'frameworks' with their O-R mappers show off applications that don't really need the full power of SQL. If you don't need it, why go through it? The ZODB is very credible - perhaps more so now than ever. Zope 3 AS would also downplay or replace the ZMI. I think there should be a skin available for configuration - ie, for adding a site (a complete application like Schoolbell, a customer CMS, etc) and maybe giving access to configuration options, like the stuff in ++etc++site, but that's it. I think the current ZMI suffers from being both a system administrator tool and application / data entry tool. I know that security settings can filter out a lot of the administrative features, but the interface that's left still feels a bit incomplete. And it raises the question "should I provide for it? should I define some zmi_menu menu items, just to be useful? should I use it as my user interface?" Django is killing us on automatic data (not system) administration pages. If web based configuration/administration (add a site, set up users, maybe select that site's skin, flush caches; process administration) was separated, then someone could build and provide something like Django's admin screens or Turbogear's Catwalk for doing the data entry. But it would be an option to use that as a view/skin/tool, and clearly marked as such. Some applications, like many CMS's, need something like the ZMI as they often separate the concept of data entry/management from how it is presented to the site's visitors. But an application like Schoolbell or a Knowledge Base may have just one skin. All data entry, display, etc, is managed through that. Having to support (or wonder about supporting) the ZMI shouldn't be a concern of those applications. It's just a point of removing distractions and concerns. This is all doable now, of course, but it's not the default (or selectable) behavior. It also makes documentation - particularly starting documentation - easier. For the good old wiki example, it wouldn't have to be explained that "you can see and edit this in the ZMI now. But if you want to put your own interface on it, you have to do this." Instead, "mkzopeinstance --create-skeleton-application name=wiki aslocal=yes.. This makes the following directories, modules, and configuration... now lets edit the standard template.. and then on to the exploding version of the blue danube!" > - Zope Suite (great name, BTW) defines a complete but limited model. It > is a simple content management system (like Zope 2 + CMF) that's easily > extended in countless ways. > > Does that match what you're suggesting? I'd hate to misrepresent your > vision. Pretty much. In my version of this vision, Zope Suite provides the full meal deal. Notice that I didn't call it 'Zope 3 Suite'. Zope 2.9 would qualify as 'Zope Suite', and its roadmap would include the transition (perhaps) from the current base to a Zope 3 CA / AS base, while right now it would say "Zope Suite continues the Zope 2 Application Server line while bringing in support for the Zope 3 CA, with support for Zope 3 AS planned for next winter's release". And boom! There we have it - a component architecture / zope.publisher / cool core technology package that is useful and usable by many, with appeal to Python "I don't need no XML or ODB" programmers, or those who like Zope's concepts but have a very different data management system; and a continuation of the Zope 3 "app server" as it exists right now, but perhaps better defined and constrained. Both of these keep the Zope 3 brand alive, and are distinct offerings. 'Zope Suite' becomes the future of Zope 2. Available now, with a roadmap towards the future where the Zope 3 features will become more prominent in the base. The release numbers might stay where they are now, 'Zope Suite 2.10, Zope Suite 2.11' until it moves (if it moves) entirely to a Zope 3 CA based foundation. It's the Zope MegaFramework. Writing for Zope Suite won't require any future 'jump' to Zope 3 AS. And developers who prefer Zope 3 AS won't have to worry about run-ins with the Zope Suite extended feature set. Anyways, that's my vision, a little bit more elaborated. But in short, you did understand it right :). -- Jeff Shell _______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com