[Zope3-dev] Re: The vision thing

[Martin Aspeli]

> - Non-technical users who just want to crank our a web application
>    with little muss and fuss.  This was the original focus of Zope 2
>    and now Plone

I think this is better served by applications on top of Zope, rather than  
trying to make the framework sit that close to the user. Like you said,  
Plone + its toolchain (Archetypes, ArchGenXML etc.) serve this purpose to  
a certain extent, at least. I think that although we'd all like  
"non-technical people" to be able to build "technically advanced  
applications", it basically degenerates down to the problem that if you  
want to let these people express themselves as richly as Python or another  
programming language allows, they'll have to learn something with the same  
degree of complexity as Python or another programming language anyway. :)

Plone + Archetypes + ArchGenXML is about a limited problem domain. You  
want a CMS-like thing, you want to create some content types with minimal  
fuzz, you want to be able to skin a bit. That's proven to be a set of  
tasks that we've reduced in complexty until a larger group of people can  
accomplish something without understanding the whole stack. Perhaps  
different applications in different problem domains can achieve the same  
thing.

I don't think it's good for a framework/appserver to try to solve all such  
cases across all problem domains, because the tradeoffs you have to make  
start getting awkward. To a certain extent, this is what happened with  
Zope 2. TTW scripts, and security models for these, and ZClassses (what  
were they, again...) and all kinds of other mechanisms that ultimately led  
to sacrifices in the cleanliness of the underlying framework and server.

> - People who know what an app server is and know they need one.
>    People who know they need to reuse applications and need tools
>    to customise them. People who know they need rich servcies, like
>    security, transactions, etc.  These are the people for whom Zope 3
>    was written.

Which I think is a good audience. Zope (2+CMF and 3, but perhaps 3 even  
more so) has proven to be a very good way of re-using elements of software  
(e.g. re-using skin elements in Zope 2+CMF, and to a deeper extent in Zope  
3), and of getting going quickly. The Zope 3 CA is a really nice  
architecture that makes it fun to write software, and Zope is good at  
taking care of teh grunt (security, transactions, authentication) that I  
don't want to take care of. In fact, I build applications on top of Plone,  
because Plone lets Zope do those things, and Plone takes care of  
consistency of UI, usability and a certain degree of integration that I  
also don't want to concern myself with.

> - People who want straightforward tools for developing small to moderate
>    complexity sites in Python.  I don't think we are servving this  
> audience
>    well.

Probably not. Separating out some of the lower level CA stuff (I still  
like Jeff's Zope 3 CA vs. Zope 3 AS idea; call it ZFC or Zed or whatever)  
will make this easier for a certain class of people. However, I think it's  
also possible that Django/TurboGears/Rails will remain good at one thing  
(possibly lighter/smaller and/or more relational-database-driven  
applications), that J2EE and .ENT will remain good at another thing  
(large, enterprise-level installations with needs to integrate with other  
more established technologies), and Zope can sit happily in the middle.

> Then there are more fragmented audiences, like people who want a dirt
> simple way to create applications based on relational databases.

Again, Django/TurboGears/Rails are good at this, and I'm not sure it's  
necessary for Zope to be able to sell itself on this point. Zope can sell  
itself on the point that it makes a lot of other things easy (e.g. using  
non-relational storages like the ZODB, transactions, authentication, etc.)  
and still has the ability to talk to relational databases with similar ORM  
concepts to what these tools use (maybe we're not quite there yet, but I  
think we should), as opposed to saying this particular thing is something  
Zope is better at than all others.

> My main point is that we need to consider each of these audiences, as
> they have separate concerns.  We need to be explicit about this and
> have messages and technical solutions tailored to each audience.

Do we? Messages, perhaps, but we should also remember that Zope  
*shouldn't* be all things to all people (because we'll fail miserably at  
that). It should allow the most flexibility, but at the end of the day,  
users will make a decision based on the trade-off between what Zope is  
naturally good at and what it can be made to do with some work.

Martin


-- 
(muted)