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
_______________________________________________
Zope3-dev mailing list
[email protected]
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
