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