Are you a student, interested in spending a summer hacking on Zope and getting paid for it?
Zope Foundation is participating in Google SoC 2008 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
Zope 2 on Python 2.5. Lots of the work concerning Zope 3 was done last year, but Zope 2 still needs to be done. Make Zope 2 work with Python 2.5.
students applying with this topic: - Ranjit Babu Kannikara
- xxxx
- xxxx
Expand the Grok introspector so that shows more information. In particular, display information about the Grok directive used, even if they are actually not used and the default behavior applies. This would be a great way for developers to learn how these directives work. (suggested by Martijn Faassen)
students applying with this topic: - xxxx
- xxxx
- xxxx
TTW in Grok: Back to the future: the return of TTW development. Let's start with baby careful steps in bringing back through the web development to Zope in the form of Grok. We need to be careful that anything developed TTW can be exported back to be a real filesystem package. Zope had this feature 10 years ago and this is still seen as some very futuristic new feature by many other web frameworks, and it can help attract beginners, so let's bring some of it back!
students applying with this topic: - xxxx
- xxxx
- xxxx
Grok and Catalog: Grok makes it easy to get going with the catalog, but adding a new index or changing an existing one still means a re-installation of the application or to write a potentially hairy low-level generation script. It'd be good if we had some more high-level tools to help out.
students applying with this topic: - xxxx
- xxxx
- xxxx
Grok relational database integration. We need a rock-solid out of the box story for using Grok with a relational database using a relational object mapper like Storm of SQLAlchemy?. Let Zope 3 schema and forms work with your RDB schemas. Explore deployments of Grok with a combination of ZODB and RDB, and RDB only. Make it as easy as possible to use and install.
students applying with this topic: - xxxx
- xxxx
- xxxx
Grok skinning security. Grok supports Zope 3 skinning. It works quite well. It's not optimal however: the default skin in Grok exposes a lot of Zope 3 views as well, and you may not want this for security in a typical deployment. Let's figure out an easy way for users to control this well.
students applying with this topic: - xxxx
- xxxx
- xxxx
Grok user and group management. Grok currently supports Zope 3's authentication infrastructure, but there's quite a bit to glue up before you can have users and groups. Look into simplifying the out of the box experience, while retaining flexibility.
students applying with this topic: - xxxx
- xxxx
- xxxx
Extending a running Zope application: Architecting and implementing a Zope component that can extend a running application in a way that plays nicely with both the component architecture and setuptools. The extensions would typically be pulled in over the network as eggs.
students applying with this topic: - xxxx
- xxxx
- xxxx
Generic broken objects implementation for ZODB that allows access to data: When classes go away persistent objects become "broken". It is impossible to remove them from the database at this point and you can not access data on them. However, this is only because we currently have an implementation that isn't able to handle those cases although the ZODB doesn't hinder us to have one. From https://blueprints.launchpad.net/zodb/+spec/generic-broken-objects.
students applying with this topic: - xxxx
- xxxx
- xxxx
Improved replication for ZODB through ZEO Raid: The ZEO RAID storage is a proxy storage that works like a RAID controller by creating a redundant array of ZEO servers. The redundancy is similar to RAID level 1 except that each ZEO server keeps a complete copy of the database. This proposal aims to improve gocept.zeoraid, fixing bugs, testing and implementing needed features.
students applying with this topic: - Dirceu Pereira Tiegs
- xxxx
- xxxx
RelStorage? support to Microsoft SQLServer?: RelStorage? is a storage implementation for ZODB that stores pickles in a relational database. This proposal aims to provide support for Microsoft SQLServer? in order to take advantage of it's replication and deployment infrastructure.
students applying with this topic: - Mehmet Ali Ozbay
- xxxx
- xxxx
Allow limiting the size of ClientStorage?'s blob cache: Currently the ClientStorage? will grow the blob cache indefinitely. We should allow some control about how large the cache may grow, e.g. by making the ClientStorage? support minimizing the blob cache. (Idea: LRU principle via mstat access time and a size-based threshold) currently). From https://blueprints.launchpad.net/zodb/+spec/limit-clienstorage-blob-cache.
students applying with this topic: - xxxx
- xxxx
- xxxx
An alternative object caching strategy for ZODB: object classification: Every ZODB connection maintains a cache that keeps objects in memory to avoid unnecessary IO work. All objects that are loaded within a transaction are put into the cache and are evicted from the cache at certain points (e.g. transaction boundaries) when cache minimization is performed. The currently implemented strategy for evicting objects is least recently used (LRU). The size of the object cache is limited by the number of objects. This size is configurable per database. Large applications have different usage patterns on objects so that the LRU strategy does not always fit those patterns effectively. Examples are: Applications with a variety of smaller and larger objects. The classical example of files stored as pdata constructs defeats the LRU caching strategy and potentially evicts heavily used (or even all) objects from the cache just to allow loading many smaller, infrequently used objects. Catalogs: Light-weight objects like brains might benefit from a higher priority of staying cached in comparison to other objects. This proposal aims to modify the ZODB to allow different cache implementations to be used, and implement a cache that performs an object classification using a configurable strategy. From https://blueprints.launchpad.net/zodb/+spec/classifying-object-cache.
students applying with this topic: - xxxx
- xxxx
- xxxx
OCQL a Query Language for (but not only) ZODB (added by Adam Groszer)
- Read the proposal: http://docs.google.com/Doc?id=ddvh6xf9_141g9sqbr
- Watch the presentation: http://docs.google.com/Presentation?id=ddvh6xf9_146gp2npm
- Some code is already there as proof of concept
- A short summary of the targets goes like this:
- Declarative Query Language
- Object-oriented Query Language
- Stable mathematical background
- Modular / component based query engine
- Speed of the query engine comparable to a usual SQL engine
- Phases of development:
- Phase 0
- Main goal of this phase is to have a fully working engine with ZODB and zope indexes. There is zero optimization involved in this phase. Therefore all properties must be indexed (mainly for speed reasons).
- parser: beeing worked on, needs to be fully working
- query optimizer: dumb/empty
- rewriter: something is there, needs to be fully working
- algebra optimizer: dumb/empty
- algebra compiler: something is there, needs to be fully working
- DB metadata and data provider: needs to be fully working with ZODB, zope.catalog, zope indexes
- skills required:
- zope technologies interfaces, components
- ZODB usage (not internals), zope.catalog, zope indexes usage and internals.
- good knowledge of the OCQL internals and theory
- (parser writing techniques)
- Phase 1
- Main goal of this phase is to have some optimization and performance testing.
- query optimizer: implement fully. There are some simple transformations that simplify the query. Seems not that hard.
- start with some performance tests
- skills required:
- very good knowledge of the OCQL internals
- graph algebra
- Phase 2
- Main goal of this phase is to have optimized queries.
- algebra optimizer: implement a cost based optimizer. A lot easier said than done. Not for the faint-hearted. Some people say that this is good for a PhD?.
- skills required:
- very good knowledge of the OCQL internals
- graph algebra
- query optimization techniques
- Phase 0
students applying with this topic: - Charith Lakshitha Paranaliyanage
- xxxx
- xxxx
zope.testing Testrunner refactoring (added by Christian Theune):
The test runner could use some cleanup and refactoring to allow making new changes easier. In addition, it would be cool if the test runner could manage its sub-processes in parallel, making better use of multi-core systems.
students applying with this topic: - Thomas Cordival
- xxxx
- xxxx
A component registry introspector (Lennart Regebro):
students applying with this topic: - Martin Lundwall
- xxxx
- xxxx
Porting apidoc to Zope2/Plone, (and possibly merging with DocFinderTab?) (Lennart Regebro):
students applying with this topic: - Uli Fouquet?
- xxxx
- xxxx
An object introspector as a debugger help (Lennart Regebro):
students applying with this topic: - Jesper Petersén
- xxxx
- xxxx
zope without zodb (added by Bernd Dorn):
Implement a package that makes it possible to run zope without zodb. The major advantage of this is, that no zeo server is needed anymore if another database (e.g sql) is used. Creating needed objects such as sites or utilities can be done at startup time and should be configured via configuration files.
students applying with this topic: - Johannes Faigle
- xxxx
- xxxx
Flint: a simple Grok-based CMS (Luciano Ramalho)
Flint is a pragmatic and light-weight CMS based on Grok which is useful out-of-the-box, allows trivial customizations to be done trivially, but showcases Grok best practices and therefore leverages the flexibility and pluggability of the Zope Component Architecture to allow deep customization and extension. See detailed description:
http://code.google.com/p/flint-cms/
students applying with this topic: - Luciano Ramalho
- xxxx
- xxxx
Grok: Introspector and other things on the way to number one (Uli Fouquet)
On the way to 1.0 release Grok has completed a remarkable set of tasks. Some things, however, need more care. Beside basic features like better testing and i18n support, a very important feature also for user acceptance might be a better introspector for the Zope component registry, the ZODB and similar runtime-information. The introspector can be improved in terms of integration (into Python/Zope), completeness and general library design quality. Eventually the introspector could support basic debugging features. All this should be done with a strong focus on usability for developers (beginners and advanced).
See the whole application at http://wiki.zope.org/gsoc/SummerOfCode2008/GrokIntrospector
students applying with this topic: - Uli Fouquet
- xxxx
- xxxx
Graphical browser for ZODB (zodbbrowser enhancements) (added by Rafael Oliveira)
The goal of this project is to provide an easy way for an user of ZODB to look inside a ZODB instance and browse through the objects. The goal will be accomplished by extending zodbbrowser, a desktop program that has the same goals but is on an early stage of development.
See the whole application at http://rafaelb.objectis.net/google-summer-of-code-2008/graphical-browser-for-zodb-zodbbrowser-enhancements/view
students applying with this topic: - Rafael Bruno Cavalhero de Oliveira
- xxxx
- xxxx
...
students applying with this topic: - xxxx
- xxxx
- xxxx
Mentors
(Mentors, please add your google accounts here)
| name: | Sidnei da Silva |
|---|---|
| google account: | sidnei.da.silva@gmail.com |
| remark: |
| name: | Martijn Faassen |
|---|---|
| google account: | martijn.faassen@gmail.com |
| remark: | Martijn is the head mentor. |
| name: | Stephan Richter |
|---|---|
| google account: | stephan.richter@gmx.com |
| remark: |
| name: | Martijn Pieters |
|---|---|
| google account: | zopatista@gmail.com |
| remark: |
| name: | Baiju M |
|---|---|
| google account: | baiju.m.mail@gmail.com |
| remark: |
| name: | Philipp von Weitershausen |
|---|---|
| google account: | fritigern@gmx.net |
| remark: |
| name: | Jodok Batlogg |
|---|---|
| google account: | jodok@lovelysystems.com |
| remark: |
| name: | Bernd Dorn |
|---|---|
| google account: | bernddorn@gmail.com |
| remark: | only for "zope without zodb" |
| name: | Leonardo Rochael |
|---|---|
| google account: | leorochael@gmail.com |
| remark: |
| name: | Malthe Borch |
|---|---|
| google account: | mborch@gmail.com |
| remark: |
| name: | Tres Seaver |
|---|---|
| google account: | tres.seaver@gmail.com |
| remark: | I'm willing to mentor repoze- or Zope2-related projects |
| name: | Kevin Smith |
|---|---|
| google account: | kevin@mcweekly.com |
| remark: |
| name: | Adam Groszer |
|---|---|
| google account: | agroszer@gmail.com |
| remark: | (sorry, but just for OCQL) |
| name: | Tino Wildenhain |
|---|---|
| google account: | tinowildenhain@gmail.com |
| remark: |
| name: | Christian Theune |
|---|---|
| google account: | ct@gocept.com |
| remark: | (Zope 3 or ZODB projects) |
| name: | Godefroid Chapelle |
|---|---|
| google account: | gotcha@bubblenet.be |
| remark: | (KSS with Zope/Grok) |
| name: | Brandon Rhodes |
|---|---|
| google account: | brandon.craig.rhodes@gmail.com |
| remark: | (relational database integration) |
| name: | Noah Gift |
|---|---|
| google account: | noah.gift@gmail.com |
| remark: | (Note I will be helping Brandon Rhodes who will be the lead mentor) |
| name: | Shane Hathaway |
|---|---|
| google account: | shane.hathaway@gmail.com |
| remark: |
| name: | Lennart Regebro |
|---|---|
| google account: | regebro@gmail.com |
| remark: | Willing to mentor the Introspector/API doc projects. |
| name: | xxxxx |
|---|---|
| google account: | xxxxx |
| remark: | xxxxx |
Mentors! Please do sign up to our google summer of code mailing list! http://mail.zope.org/mailman/listinfo/gsoc
Resources
- gsoc mail list
- Zope Foundation's Application Questionnaire 2008
- Mentors, please read this excellent Mentor HOWTO
- IRC Channel: #zope3-dev at irc.freenode.net
- If you're interested in the Summer of Code but want to focus on Plone, the Plone Foundation is also a mentoring organization so you might be able to find projects at Plone Summer of code 2008.