Gallery 3 begins

Hello everybody!

As some of you may have noticed already the Gallery2-Team announced a complete rewrite of the Gallery project named "Gallery3", "G3" in short (read http://gallery.menalto.com/gallery_3_begins). I agree with the G2 devs that a rewrite at this point makes a lot of sense. The latest version of G2.3 provides good funtionality, but has grown heavyweight/complex and slow. However, the announcement of G3 has great impact on the future of the Drupal integration module(s) as well. What does this mean for us?

1. G3 builds on the nice Kohana framework (http://kohanaphp.com/), which allows for a lightweight and flexible implementation. It also makes it really easy to extend or override existing functionality in G3. Thats good news for us, as it will probably allow for better integration (especially the "look and feel" integration). Because G3 is in early stages and the embedding API has not been defined yet, I cant estimate the feature set of G3+Drupal in detail.

2. On the other hand, G3 will likely be incompatible with G2 (on the API and database level). What means the gallery_addon modules I'm currently working on will require major modifications to adapt to the new structure. If G3 is going to be implemented in a consequent manner, we can expect a good chance of tight integration with Drupal.

For that reason I decided to stop development of the addon modules and start tracking the G3 progress, so that we can have a Drupal 6 (and/or 7) integration module at the time when G3 will be released (targeted for February 2009 atm). Depending on the speed of development of Gallery3 I hope to have CCK/Views integration at that time as well. But we will probably NOT have a G2+D6 compatible release of the addon modules anymore.

Everyone interested in early testing and feedback of embedded G3 please send me a mail, so that I know who to deal with.

Cheers, Thilo (alias profix898)

Update

I'm wondering if we shouldn't take what we can from gallery and build a "feature port" in drupal.

To be honest I have been thinking about something like this last summer as well. However, after spending hours in IRC and talking to several people face to face, I dont think that should be an option (at least not for this module). Let me tell you why.

Developers perspective: A feature port is possible of course, but for code level transfer of existing Gallery2 functionality we would need to reimplement the whole model-view-controller pattern in the Drupal module. IMO it would be easier to simply rewrite most of the features from scratch utilizing Drupal framework benefits such as the node system, etc. However, thats only a vague argument against a port, the user perspective is much more compelling.

User pespective: Image/imagefield and friends have evolved a lot in 2008, so that all the basic functionality is available with Drupal modules already. With the latest status of these modules in mind, it doesnt make sense to feature port all of Gallery2 into a new module. Most features can just be added to existing Drupal functionality. Gallery2 is a separate application, separate to install and maintain, making it more difficult for newbies to setup and use, and difficult for users to integrate seamlessly into the Drupal landscape. The question is: Why would users still prefer Gallery?

The good news is that Gallery3 will be different from Gallery2 in many aspects. Gallery3 will use jQuery and jQuery UI instead of YUI, making it somewhat compatible with Drupal (especially with Drupal 7 that will probably ship with jQuery UI in core). Also G3 will be using a theming layer similar to PHPTemplate (no longer Smarty) bringing it much closer to Drupal with respect to theming and uniform appearance. But still, is this enough for users to run Drupal+Gallery3 instead of just Drupal?

I think we can turn Gallery's most obvious disadvantage into its biggest strength, namely the fact that it is a separate application. Here is what I have in mind for Gallery3 and Drupal7.

Gallery module for Drupal 6.x integrates a single G2 instance with Drupal. For the next version I would like to interface with multiple galleries based on a clean object-oriented model (php 5.2+ only support). There are three different aspect I'm currently taken into account for defining the structure for the new module (lets call it GNG = Gallery Next Generation).

A) Integration level
There should be two different integration levels supported with GNG. Level 1, the 'Embedded mode', behaves just like we are used to with the current gallery module. The embedded mode simply renders an embedded gallery page (and - of course - supports other features like G2: filter tags, etc.). Level 2, the 'Field level integration', will provide a field for referencing or actually representing a Gallery entity. The moment the 'fields in core' patch hits Drupal 7 we get the (probably) unique opportunity to provide field-level integration without duplicating G3 entities in Drupal.

B) Interaction level
I'm thinking of two different interfaces for "talking" to a G3 instance. Level 1, the 'Local' mode, uses an API provided by G3 on the PHP level. Thats the situation we have in the current module. Because Gallery3 is build with a RESTful API we can actually have remote access to all (or at least most) of G3's functionality. The remote protocol of G2 only supported the most basic features. Level 2, the 'Remote' mode, interfaces G3 through the REST-API making it possible to even integrate with G3 instances on a remote server (without direct file/db access).

Not everything explained in A) and B) will necessarily work in combination. And one thing that makes the situation more complicated, is the permission model used in this context.

C) Permission model
In principle, we can think of two distinct models. Model 1, the 'user synchronization' model, maintains a 1:1 sync of users in Drupal and their Gallery counterparts. This is the model used in the current version of gallery model. Another possible option is Model 2, the 'single user interaction' model. Here all communication with the Gallery instance happens with the same single user account.

Single user interaction would be especially useful in combination with a remote Gallery instance. We could have a Gallery installation acting as an image or media repository (an 'ImageTank'). People could manage all media in a central repository (and with a powerful GUI), but only exposing a subset of items to the public (to the Drupal website in this case).

I hope this short introduction helps to understand my perspective on Gallery3. And why I think its still worth to maintain a module for integrating an external media management application.

Cheers, Thilo