The Gallery project is pleased to participate in the 2006 Google Summer of Code.
Here are some of our ideas about what you can work on. Pick one or two of the tasks below and talk to us about it and we'll help you make a proposal to Google. Since we're getting a flood of people who are interested in working on tasks, you should be aware of a few things:
We're going to be unable to answer each and every request for more information about a task. Try as we might, there are just not enough hours in the day. So to arm yourself to make a winning proposal, you should have a good knowledge of PHP and web based application development. You should have a copy of Gallery 2 installed and you should have played with it enough to get an idea of the feature set. You should spend some time reading the Gallery 2 development documents. You should at least crack open the code and take a look at what's inside so that you can get an understanding G2 modules and themes. You're going to need to know this stuff in order to write a proposal that we (and Google) are willing to accept. You should also be prepared to write good documentation for your work, write extensive unit tests, follow our strict code style and interact with us on our IRC channel (#gallery on irc.freenode.net).
We absolutely want you to submit a proposal! We'd like you to get funded by Google -- this is good for you and it's good for us, and we'd love to have you working on the code base. We will be happy to answer any specific questions you have about the application vision, design and implementation. The more specific the question the better.
After the deadline, Google will give us the applications and we'll choose as many of the best proposals as we can effectively mentor. We don't expect to see any until after the deadline has passed. Once we get the applications, we'll be selecting for quality. The more thoroughly that you demonstrate an understanding of G2 and the work entailed by your proposal, the greater the chance that we'll accept it. For example, a proposal that merely repeats back what we already have on the ideas page is not good indication that you actually understand the work that's required. The quality of your written English is also very important. We're an English speaking team and will expect you to be able to write good code, comments, documentation, email messages and irc chat in English. Take your time to dot your i's and cross your t's and use the correct terminology because you can be sure that you're competing against others who will do so.
If you want to get your proposal accepted, the best technique is to download G2 and start hacking on it and trying to implement the idea. If you spend an hour or two on the actual code itself, I suspect that you'll be able to write a much more thorough proposal (with supporting design documents, mockups etc) which in turn will be much easier for us to accept. A couple of hours now can lock in your $4500 stipend this summer.
Hopefully after you've armed yourself with the information above, the following task synopses will provided you with enough information for you to figure out what is really involved in drawing it to completion.
Gallery 2 currently works with a variety of SQL backends (e.g. MySQL, PostgreSQL, Oracle, DB2). SQLite offers fast, SQL access to a flatfile database and can be easier to configure than a traditional SQL database server.
Gallery 2 currently lacks some features that could turn any Gallery 2 powered site into a full photoblog package. The ability for site admins to add static content like photographer profiles, set future publish dates for photos and albums, notify subscribed members of changes and other similar task are not currently available.
Gallery 2's EXIF module currently handles embedded EXIF and IPTC data in jpeg and tiff images. Its current functionality includes extracting description, keyword and the timestamp from the embedded data and copying this data to the respective G2 item attributes; offering a block to show EXIF / IPTC data on photo pages; and a maintenance task to re-extract / capture the timestamp from the EXIF / IPTC data into the G2 item property
There are several key features that are missing from the EXIF module including storing the EXIF/IPTC data in the database instead of extracting it on each page load; writing EXIF/IPTC data - currently we have read-only access to the data; and searching EXIF/IPTC data
Gallery 1 offers a mirroring function that could be expanded for Gallery 2. The advanced mirroring would mean Gallery 2 would provide mirroring and load balancing, with some flexibility.
The user would configure 1 or more "alternate" image locations (currently called mirrors). He would also have the option of considering the primary in the list or ignoring it (ie, ignore if on DSL, use if hosted in a real environment).
On setups where the configuration has more than 2 "alternates" (including if they primary site is considered viable) a drop-down list on the main site would be available and have the option of all, mirror 1 and mirror 2. All would be load balanced, gallery pulls every Nth image from one mirror vs. another. Specifying one or the other mirror would pull from that mirror.
There are many benefits to this. Anyone with more than one "alternate" OR one alternate and a viable primary site can benefit from load balancing AND at the same time, possibly provide two locations for the user to pull images from. This would be especially useful if the user had alternate images on a server in europe, asia or somewhere far away from his main server. Then, any visitor finding images loading slow can choose to use one closer to him/her.
The admin should be able to allow alternates to even be picked (some may want to force load balanced) and should also be allowed to pick the default (load balanced "all" or one of the specified mirrors).
Gallery2 uses an adjacency matrix in the database to store the parent-child relationship, with a cache of ancestors for better performance. But if we were to convert that to the Modified Preorder Tree Traversal form, we may get a significant performance boost. There are complicating factors in getting this exactly right, including dealing with pessimistic locking and the Gallery permissions system. But getting this right could really be worth it.
The current slideshow displays photos quite nicely. Flickr takes slideshows several steps further with a Flash-based slideshow that provides thumbnail navigation, fade transitions between images, and slideshow controllers that minimizes smoothly. The addition of admin tools to rotate and manipulate images when viewed in the slideshow would be an incredible addition (ala iPhoto).
Gallery 2 is a large framework that takes advantage of many aspects of PHP that are not available with Safe Mode enabled. This is an oft requested feature which would require considerable amount of investigation and tweaks to the core framework. But if we could figure out how to address the various issues related to safe mode it would make many users very happy.
Gallery 2 is designed to be integrated into other applications. We've made great strides in integrating it into Xaraya, Mambo, WordPress, Drupal, PHP-Nuke and other applications. All of these integrations require a certain amount of fiddling around with technical packages. Creating a single bridging application that enables integration with remote applications using a point and click interface would ease integrations and drive user acceptance.
An active Gallery 2 site can have numerous events occur over time (new photos are added, new comments are added, new members register, etc.). A generic e-mail/notification module that lets other modules use it for sending e-mail when an event occurs would be a welcome feature.
There are tons of other things you could play with. Get ideas from:
And let us know!
