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

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

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

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! :)


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

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

Reply via email to