Fast Gallery architecture for the next version

The current fast gallery module has become pretty big and hard to maintain. For the next version I've been thinking about a new and more flexible way. I've come up with the following system:

There is a storage engine that can be accessed over an interface. Default will be the plain DB (which corresponds to the current storage system of fast gallery). The user can decide which mode he wants to use for building up the gallery. The interface allows other people to write storage engines for fast gallery, maybe someone wants to store the data as xml? or maybe no storing at all, but everything on the fly? … everything will be possible, as long as the interface will be implemented.

Main principle will though still be the same: Fast gallery is watching a file folder and updates the gallery by cron job or manually.

There is going to be the controller -> which will mainly be the Drupal integration and the Theming part which is going to be more flexible too using tpl files.

Goal of this will be:

  • More flexibility
  • Better modulization
  • Easier to maintain
  • Easier to use for the enduser

The base version is going to loose a lot of the functionality used in previous versions (for example, exif support, different sorting options). These are going to be optional plugins.

I'm always open for inputs and ideas. This is open-source, so please help getting fast gallery to the next level.