[Zope3-dev] Re: Google SoC Project

[Martin Aspeli]

Hi Stephan!

> Nate sent just a message that I am interested in a SoC project with the  
> Plone
> Foundation. Okay, let me write something too.

It feels almost like cheating, since you're likely to know more than any  
potential mentor about the stuff you're working on, but I think it'd be a  
great idea to give you more time and compensation for contribution. ;-)

> I think doing a SoC project would be a lot of fun and would give me some  
> time
> to work on Zope 3. Unfortunately, I am a little bit lost to what I could  
> do
> that widely benefits Zope 3, Zope 2, CMF and Plone. Here are some of my
> ideas, some are stolen from the Plone project suggestions:

I think it's important (for Google) that it's the Plone Foundation that  
has been approved for mentorship, not Zope Corp or the Zope Foundation (if  
there is/will be such a thing...). That means that what you do under this  
guise needs to be directly relatable to and beneficial for Plone.

> 1. Finish the ZSCP site[1]
>
> I think that the ZSCP process will be vital for controlling software  
> quality
> in the future and provide people with a valuable resource for additional  
> Zope
> software. My original proposal was modest by design, since I did not
> anticipate to have much time to work on a larger vision. With the SoC  
> project
> I could finish the implementation of the proposal and extend the scope  
> to be
> more inclusive of existing packages/products, especially with regard to
> Plone.
>
> This project would fit the SoC program well, since its scope is  
> well-defined
> and extensible.
>
> .. [1] http://mail.zope.org/pipermail/zope3-dev/2006-February/018319.html

I have two reservation about this - the first is that the process seems  
very arduous (i.e. there are a *lot* of tickboxes in that table, and there  
is the potential to create a lot of red tape). The second is that without  
a large amount of buy-in from the wider community (and in the context of  
SoC, that means primarily the Plone community), it won't gain the  
necessary traction to be relevant.

To be sure, I support the principle of the ZSCP, but it is a very hard  
*social* problem (as opposed to a purely technical one) that may not fit  
the model of a single student working on it for a few months.

As I recall, much of the process was also biased (for good reasons!)  
towards pure Zope 3 products, which may actually mean that the majority of  
Plone components could never fully comply with the standard... which in  
turn doesn't make for a great case of the Plone Foundation Summer-of-Code  
application. :)

> 2. Implement Local Sites in ZCML
>
> I already mentioned this several times: It would be very nice, if we  
> could
> define local sites in ZCML. I understand this task very well and could  
> write
> a proposal and implement it in a well-defined time frame. BTW, this task  
> is a
> "must happen", if we want to port something like Plone to Zope 3  
> eventually.
>
> This project might be too short for the Google SoC. But I think it has a  
> lot
> of potential.

I think that anything that solves one or two of these for Zope 3 would be  
highly relevant to Plone:

  - Local-ness - everything in CMF/Plone is about "local". Only when  
product X is installed should X's functionality be exposed, and before X  
is installed, something that's registered in ZCML or whatnot could  
possibly break. People expect to have several Plone sites in one Zope  
instance and configure them differently.

I'm not entirely sure how this fits with ZCML, though, since ZCML is  
inherently global (i.e. we can't hard-code site names in ZCML ;-), but I'm  
guessing you're talking about a more generalisable way to install things  
locally and have things only take effect when locally enabled?

  - Through-the-web customisability of *templates*. I'm not convinced we  
need TTW-classes and components and logic - those things fit progammer  
minds and programmer minds don't mind filesystems and like svn. But people  
using Plone are *very often* drawn to it because the ease with which they  
can override/customise page templates (and by extension visual "logic",  
layout, etc.) without leaving their web browser or learn a large stack of  
technologies. It's not an ideal model, and we need good ways of getting  
out of the ZODB and into a "skin product" or similar. But we are extremely  
reluctant to make use of views with page templates (as opposed to page  
templates that acquire views and then call its methods) in Plone precisely  
because it means sacrificing TTW customisability.

> 3. Optimize ZCML
>
> We talked about it many times. The startup time for Zope 3 is too long.  
> In
> part this is due to the schema field conversion and verification of the  
> ZCML
> attributes. I would like to work with Jim on some strategies to optimize  
> the
> startup time by reducing the ZCML processing. Over the years we have  
> thought
> of several solutions, but they all involved a lot of hard labor that  
> noone
> was willing to do for free. Well, getting paid to do it, is a good
> motivator. ;-) Of course, this is also very important to the Plone  
> people as
> more and more ZCML is being used.
>
> I think that this project would have exactly the right timeframe and  
> scope for
> a Google SoC project.

This is very Zope3-focused, though, which may make it a bit of hard sell  
as a Plone Foundation project. It sounds like a good idea, though (of  
course, Zope 3 already has the fastest startup time of any of the  
components we use, so we don't care as much as pure Zope 3 people do).

I would possibly be more excited by making it possible to re-load the  
component architecture without re-starting Zope. There's a lot of  
stop-start in Zope3/Five development at the moment, and it slows people  
down. It also makes it impossible to make TTW interfaces that persist  
configuration on the filesystem in ZCML files and have that configuration  
take effect immediately (perhaps not a great idea, though - local  
components will likely be the way things like this are done).

> 4. Implement a Query Framework and Language for Zope
>
> Through my contract work I have recently played extensively with  
> catalogs and
> indices in Zope 3. Furthermore I have used hurry.query for all my  
> searches. I
> think hurry,query could be extended to become a full-featured query  
> framework
> for Zope, including ad-hoc searches of objects. Furthermore, over and  
> over
> again we get requests from people wanting to quickly query the ZODB (or  
> at
> least the content space). I think it would be possible to build a query
> language on top of hurry.query.
>
> This project would be somewhat experimental, but fit the spirit of  
> Google's
> SoC.

I don't know anything about hurry.query, though having more Zope3-ish ways  
of dealing with the portal_catalog and other searches would be useful.

Please note that Dough Winter (aka winjer) did a lot of good work at the  
Archipelago sprint on making some generic query interfaces to a drive a  
widget that's meant to query the catalog, LDAP, and other sources. I  
believe this was a Zope 3 package primarily.

> 5. Implement Portlets
>
> Implement portlets in the sense of JSR 168. I think that a Zope portlet
> implementation in the spirit of JSR 168 is very feasible and would  
> benefit a
> wide variety of Zope users. Achieving full JSR 168 compatibility is  
> probably
> a lot more tricky and a risky objective, since I do not know the entire
> standard.
>
> I think if the project would state that we try to implement portlets and  
> only
> try to discover the feasibility of JSR 168 compliance, then this could  
> be a
> decent S-C project. But I am not as thrilled about it, since it involves  
> a
> standard. ;-)

PLIP 118 (http://plone.org/products/plone/roadmap/118 ... it's a little  
rough still) is on the SoC list, and is something that we really want to  
push for Plone 3.0. PlonePortlets is a zope2-style product that has been  
used extensively in production (by PloneSolutions primarily) and solves a  
lot of the portlet use cases that people have "in the wild". We wanted to  
leverage the viewlet architecture for this, though we are more using the  
interfaces than the implementation, because using ZCML to register  
portlets won't work. Basically, the idea is:

  - You make a Smart Folder (aka Topic, canned query) and turn it into a  
portlet
  - .. or you pick a type of portlet (e.g. an RSS feed portlet),  
instantiate it, configure it

  - Then you assign that portlet to one of the portlet columns
  - ... or to your personal "dashboard"

  - Portlets can be grouped/assigned site-wide, by user group, or on a  
per-user basis

The idea we had was to use a marker interface IPortletData to determine  
what could supply data to a portlet (e.g. a smart folder, or a custom  
simple/zope3 content type that held configuration data). We'd make  
adapters to IViewlet (or rather, a sub-interface IContentViewlet to  
distinguish them more easily from basic viewlets) that could render a  
particular kind of IPortletData as a viewlet. A special kind of  
IViewletManager would find portlets assigned to it and visible in the  
current context (e.g. depending on user, group and current content object)  
by talking to a local (but site-wide) utility IPortletRetriever, which  
stores all the assignments (IPortletAssignment) internally (PlonePortlets  
already has a lot of this logic in place). It would get back IViewlets to  
render. The UI for assigning portlets to different slots ("this portlet is  
displayed for users in the Administrators group, on all IATDocuments, in  
the left hand portlet column) would talk to the retriever. We also  
envisaged a local utility that actually stored the IPortletData (aka  
portlet configuration) instances where these were not applied to normal  
content objects, so as to keep portlets out of content space.

Right ... that was a lot of detail, because I think this would be one of  
the most interesting thing from a Plone perspective for you to work on  
(along-side local components/patterns and TTW skin customisation), not at  
least because you understand the viewlet problem space very well. Geir  
Baekholt or Dorneles or me (or a combination) could probably mentor on  
Plone use cases (esp. the first two, since they very much wrote  
PlonePortlets and know all the real-world use cases their customers need).

JSR168 sounds like the kind of thing we'd love to have on paper. I have no  
idea if there's scope for true interoperability with Java/other systems.  
If there is, it'd be a huge benefit. If it's only to say "we support this"  
it'll look good for Plone but possibly not be as useful. It'd probably  
also inspire use cases beyond those found in PlonePortlets.

Thanks for showing an interest Stephan - we truly could benefit a lot from  
your expertise and your development skills! :)

Martin

-- 
"You can just adapt yourself out of it..." // Archipelago sprint 26/04/2006