- 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

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.



Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to