Zope 3 wiki →
last edited 2 months ago by simon
created: 2007-03-04

Summer of Code 2007

Are you a student, interested in spending a summer hacking on Zope and getting paid for it?

Zope Foundation is participating in Google SoC 2007 as a mentoring organization. If you're a student and would like to improve Zope by working on one of the Zope Foundation projects (Zope 2, Zope 3, CMF, Grok, ...), apply to the Google Summer of Code. Below is a list of potential projects that you can work on, but feel free to suggest your own ideas as well. Note that your project suggestion should involve a definite goal of one of the Zope Foundation projects!

If you're a Zope core committer (and only if you are a Zope core committer) and would like to mentor a student, please add yourself to the mentor list below. Please also consider suggesting one or more possible student projects.

If you have applied or are just interested or have a question, subscribe and post to the gsoc@zope.org mailinglist.

Suggested projects

  • Improve packaging of Zope 3 and Zope 2 (suggested by Philipp von Weitershausen)

    In the upcoming 3.4 version, Zope 3 will use Python Eggs (Python's new packaging mechanism) for the first time. That does not mean the eggification of Zope is done. The zope.app package is still packaged as one big egg instead of individual packages (zope.app.container, zope.app.catalog, etc.). Splitting up zope.app into separate eggs will take a careful analysis and reduction of package interdependencies. The second part of this project would be to look at the packaging of Zope 2. Zope 2 contains most Zope 3 libraries for a while now, so integrating them as eggs would be a logical conclusion, if not even attempting to package Zope 2 as a collection of eggs.

  • Improve Zope's WSGI capabilities (suggested by Sidnei da Silva and Philipp von Weitershausen)

    While Zope 3 has been supporting and using WSGI for a while now, there are still several interesting areas to explore. For one, it would be great to see Zope 3 using paste.deploy for server configuration so that using one of the many paste middlewares becomes a matter of configuration. Furthermore, we would like to see Zope being integrated with IIS (through isapi_wsgi) and Apache (through mod_python) using WSGI (instead of using those traditional HTTP servers as HTTP proxies in front of the Zope webserver). One of the suggested goals of this project could be the possibility to run Zope in a hosted webserver environment where only Apache and mod_python are available.

  • Run Zope 3 using Python 2.5 (suggested by Baiju M)

    Now Zope 3 will only run on Python 2.4 . A lot of code changes are required especially in C code to run Zope 3 on Python 2.5 . This project does not target Zope 2, may be another project can be created for that. This project can be divided into three parts: 1) Analyze code changes required. 2) Create a proposal to make changes. 3) Implement proposal . Project Details: Zope3UsingPython25

  • Analysis and optimization of Zope 3 startup (suggested by Martijn Faassen, but also see below)

    Analyse (through profiling) Zope 3 startup to see what's taking up the time, and based on results, work towards improving startup time of Zope 3. This potentially involves optimizing ZCML loading (see project suggestion below), but may also involve other measures as suggested by this analysis.

  • Optimizing and enhancing ZCML for quicker startup (suggested by Stephan Richter)

    Global components are commonly configured using an XML-based configuration language called ZCML. Currently a problem in Zope 3 is the startup time. Some code profiling has determined that most of the time in the startup process is lost in parsing, converting and validating ZCML directives with their schemas. Thus, this startup problem is not purely a Zope 3 problem, but one that affects everyone using ZCML.

    This problem can be addressed in several ways. The most obvious one to Zope 2 developers would be not to restart the application server, but only reload the packages and modules that were affected by the code changes. This approach has been used in Zope 2 for many years, but it several serious problems and some of the smartest people have not been able to completely solve the problems.

    The second approach is to reduce the ZCML processing time, which could be integrated into the reload mechanism for Zope 2. This can be accomplished by storing some binary representation of the ZCML, similarly to *.pyc files in Python. Again there are several choices to consider and they should probably all be tried. The first solution would be to store a pickle of each parsed directive, namely the action and its arguments. There would be one pickle file fore each ZCML file. When the ZCML file changed, the pickle would be updated. Pickle loading would be much faster than pure ZCML loading, since no XML-parsing, value conversion and schema validation would be necessary.

    On the other hand, ZCML creates actions that are eventually executed. Actions are created by executing the directive handlers. Thus the optimization in this approach would be even greater. The problem with this approach is that not all directives are easily pickable. Directive handlers often create new types/classes on the fly. This problem could be solved by ensuring that directives only create pickable actions. Clearly, this would require a lot more work, since you would have to go through all directives to ensure their pickability and also provide fallbacks for 3rd-party directives.

    Another task in this line of work would be to create Python actions for all directives first. This way developers could choose to write configuration in Python or ZCML. Projects like Grok would benefit from this development.

    Overall, the performance of ZCML could be improved drastically either way and that the benefit would be immediately visible for anyone using ZCML, including Zope 2 developers using Zope 3 components via Five.

    By the way, if you do this project, you will be a hero of the Zope community! :-)

  • Update the RestrictedPython? package to work with Python 2.5 (suggested by Jim Fulton)

    Zope's security-protection system uses the RestrictedPython? package to add security checks to untrusted Python code. (Zope 3 makes very limited use of this. Zope 2 uses it extensively.) The Python compiler changed quite a bit in Python 2.5. The RestrictedPython? package will have to be updated to reflect these changes. It would also be helpful to write some documentation of the way that RestrictedPython? works to make it easier to make future changes.

    This is a potentially pretty interesting task for a student interested in language compilation.

    This is a highly important project. We will not be able to support Python 2.5 in Zope until it is done.

  • Make Zope 3 (and Grok) work with alternative templating languages (suggested by Martijn Faassen)

    There have been quite a few developments recently in Python-based web templating languages. It would be nice if Zope could easily take advantage of these languages. Interesting templating languages to support would be Genshi, Mako and XSLT.

    Also interesting is a system called Buffet, used by CherryPy? as a universal templating language plugin system. While this is only available for CherryPy?, the Pylons project has a fork. Buffet uses setuptools' entry point mechanism so that any templating language supporting Buffet automatically plugs into CherryPy?. It would be great if templating languages that declared such an entry point would also automatically plug into Zope 3.

  • Improve Grok (suggested by Martijn Faassen)

    Grok is a new project that aims to make Zope 3 application development more agile and easier to get started with. There are many things that need improving with Grok (see also the launchpad page). Potential Grok related projects include:

    • building an admin UI for Grok (which is less ambitious than the traditional Zope ZMI; it only allows application installation and inspection, not through the web application construction)
    • expanding on the Grok reference and tutorial.
    • Integrating more existing Zope 3 components and extensions with Grok.

    See http://grok.zope.org for more information.

  • Extend the WSGI and Twisted integration in Zope 2 (suggested by Lennart Regebro).

    Zope 2 can currently use twisted via WSGI for HTTP access, but this should be extended to WebDAV? and FTP as well.

  • Add zope3 support for json and AJAX widgets in formlib. (suggested by Paul Carduner)

    Currently, formlib generates html fields that can be submitted all at once and then processed accordingly. One common pattern used is to just change attributes on content objects. All the field data is submitted via the request object, then verified and applied by formlib. This is great for simple applications with simple content objects where speed of data entry and manipulation isn't a high priority. However, for larger projects where there is lots of data which needs to be searched/modified/added in a timely manner, AJAX provides a good solution.

    For example, in the schooltool project there is the navigation paradigm of: search for an object, view the object, display the object; where each step is a complete new page. AJAXifying? this paradigm would reduce these pages into one. Search results would be loaded on the fly as search keys were typed. Clicking on an item in the search results would load data about the object in line (while still looking at the search results). Then clicking on one attribute of the object would load a widget for editing that one attribute. To accomplish this style of navigation the right way (the Zope3 way) would require a number of steps:

    • Create widgets that serve the functions of displaying, editing, and submitting a form field.

      For example, the widget for a TextLine? schema field would work like this. Upon rendering you would see the text stored in the field. Clicking the text would turn it into a text input with the previous data already there. Type modified text. Hitting Return/Enter would turn the input field into plain text and submit the new data. So, each widget would act like its entirely own form.

    • Create a json traversal namespace where requests get sent for processing. For example, our page might have the url http://localhost/page.html. Then HTTP requests from the individual widgets would be sent to the http://localhost/page.html/++json++/name.of.field url. Transferring data using the json format would make integration with javascript libraries much easier and be lightweight in the process!

    • Extend formlib to handle data submission with the json format and the generation of ajaxified forms and subforms. It would also be nice if forms could mix ajaxified and traditional form elements. For example, we might click on an object and it will load an actual form inline (like a SubPageEditForm?) which gets submitted altogether using an ajaxified button.

    • Look at the jsonserver (http://codespeak.net/svn/z3/jsonserver/) and KSS (http://kssproject.org) projects.

  • GenericSetup? improvements (Suggested by Lennart Regebro) CPS has some improvements to GenericSetup?. Most importantly, the upgrade steps is a way to easily make upgrading scripts that know when they need to be applied. This should be merged into GenericSetup? proper. See also http://www.openplans.org/projects/enterprising

  • IncrementalSearch? as ZCatalog? engine. (Suggested by Lennart Regebro) ZCatalog? performance breaks down when you have large sites (supposedly around 300.000 documents, although I haven't tested myself). This is at least partly because ZCatalog? creates large intermediate result sets during the searching. The internal ZCatalog? engine should be replaced with Dieter Maurers IncrementalSearch? to get rid of this problem. See also http://www.openplans.org/projects/enterprising

    • ... more ... ?

  • ... your project! If you're a student and have a project suggestion of your own, simply use the edit link on the left and add your suggestion.

Mentors

(Mentors, please add your google accounts here)

  • Philipp von Weitershausen (Google account philikon@googlemail.com)
  • Stephan Richter (Google account stephan.richter_at_gmail.com)
  • Martijn Pieters (Google account zopatista (at) gmail.com)
  • Baiju M (Google account baiju.m.mail AT gmail.com)
  • Lennart Regebro (Google account regebro@gmail.com)
  • Jodok Batlogg (Google account batlogg@gmail.com)

Resources



( 99 subscribers )