[Zope-dev] Functional areas of Zope

[Jim Fulton]

On Mon, Oct 18, 2010 at 7:51 AM, Thomas Lotze <thomas at thomas-lotze.de> wrote:
> Hi all,
>
> at the Zope summit in September, we were talking about what Zope
> actually is or should be and how to define the goal of the Zope
> project. This led to the idea of identifying the functional areas
> of Zope.

I don't think that's quite right. I don't remember exactly what we
said, but I would hope that we wouldn't contradict the decision, made
some time ago that Zope, unless qualified (as in "Zope Community" or
"Zope Toolkit"), refers to Zope 2.  If we did, it would have been
because we were speaking informally.

> I'd like to pursue this by starting a discussion about
> Zope's functional areas among the developer community and hope to
> come up with a number of commonly agreed-upon items. Wherever it
> matters, I suggest limiting ourselves to discussing the ZTK in
> order to keep things focussed.

I think you mean "ZTK" functional areas.  Or, perhaps better, Zope
Community functional areas.

> As functional areas (for some examples, see below), we consider
> diverse, broadly defined tasks and problems that a web developer
> is being faced with, and that a web framework ought to have an
> answer for. We hope to be able to define better what Zope is and
> is not and how it compares to other web frameworks by starting
> from a set of functional areas and trying to state Zope's answer
> to each of them.

My opinion, stated at the DZUG, is that Zope is *not* a framework.
I think treating it as a framework was an early mistake that has
haunted us for years.

The ZTK (which we should have had from the beginning) is a
collection of frameworks that support Zope the application.

> Another benefit from having a grip on functional areas of Zope

I'm sorry did you mention benefits above?   I dont see them.

> the project would be the possibility to organise the large and
> grown set of individual packages that make up Zope's code.

OK, so a benefit is to organize packages. I guess I can see that.
So, a documentation exercise.  Perhaps this would be better
left to people writing documentation.

I have a feeling that some people want to organize community
development efforts around these areas, although I don't think you're
saying that, although perhaps you hint at that in your summary.

...

> - client-side programming framework (no good solution so far, people use
>  all sorts of Javascript technologies and programming styles)

Huh? There are many good client side development libraries. There
isn't one obviously "right" javascript library, but there shouldn't
be.  (I think Tim made a mistake when he included TOOWTDI in the Zen
of Python).

I'm not going to fault someone for trying to come up with something
newer and better, but I don't think it should be a Zope functional
area.

OTOH, I do agree with Lawrence that there's a lot of value in
collaborating on how to integrate existing JS frameworks with the Zope
server-side frameworks.  Of particular interest to me are:

- integrating with form-generation libraries based on zope.schema,

- transactional REST interfaces, and

- perhaps more direct ZODB data access <shrug>.

> I hope for the discussion to produce a list of functional areas
> that most developers agree upon, maybe further areas that need more
> consideration, and possibly even some clues about Zope's answers to the
> challenges of each functional area.

If nothing else, I think the discussion will be valuable.

> Thank you very much for your participation.

Thanks for spuring discussion.

Jim

--
Jim Fulton