Hey everyone,
Nate sent just a message that I am interested in a SoC project with the Plone
Foundation. Okay, let me write something too.
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:
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
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.
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.
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.
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. ;-)
That's it! Let me know, if you can think of any tasks that would bring us all
forward.
Regards,
Stephan
--
Stephan Richter
CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
