Gallery API Changes

Bharat said:
Hi, all.

We're going to make some API changes in Gallery 2.1, but we want to group them all together so that we can make one pass through all of our modules to get them up to the new form. This set of changes includes many large and small optimizations to the framework that break backwards
compatibility. We've done as much as we can without breaking compatibility but in order to really move forward we need the latitude to make the changes that are necessary.

Right now we're tracking the list of things that we plan to work on in a comment in GalleryModule::getApiVersion(). I'm including it below so that you can get an idea of what's coming. You can also always track any API changes that we've made since 2.0 here:

http://codex.gallery2.org/index.php/Gallery2:API_Changes_Since_The_Last_Release

So as to avoid churning CVS HEAD, we're going to do the work in a separate branch: BRANCH_API_DEV. If you would like to keep up with us and help out, you can switch to that branch and help us test. In the meantime, we're going to try to keep changes to HEAD down to a minimum in order to avoid causing painful merges with our work in the branch. We'll probably wind up touching practically every file in G2 so merging will be painful.

The target date for reintegrating the branch back into HEAD is sometime in mid December. The target date for the 2.1 release should be at least 3 weeks after that to allow things to settle out a little bit. The holidays are almost upon us (here in the US, anyway) so this may slip a little bit.

If you're doing module development for 2.1, you should probably follow us into the branch and hang out in #gallery. We'll help you as best we can.

regards,
-Bharat

=============

* TODO for the next major version bump:
* - Remove GalleryModule::loadItemDetails()
* - Remove DatabaseStorageExtras::_loadOldStyleSqlFiles
* - Consider removing isRecommendedDuringInstall() since
* we now have 4 different types of installs
* - Fix DatabaseStorageExtras::_parseSqlTemplate so that it no longer
* accepts database files of the old form (A|R)_Table_#_# but requires
* the new form (A|R)_Table_#.# instead
* - Flatten classes/GalleryStorage/DatabaseStorage/schema under
* GalleryStorage; we're no longer going to seriously attempt to do
* any other kind of storage besides DatabaseStorage. Roll as much
* functionality as possible up into GalleryStorage.class
* - Uncomment new code in GallerySession::_shouldSaveSession that
* will require modules not to call translate() from contructors
* - Combine userId/groupId columns in all our various tables into one
* column (entityId?)
* - Allow getItemSummaries to return a file to include, instead of
* just HTML so that item summaries can be integrated into the master
* template.
* - Change GalleryUrlGenerator to take an $options array instead of
* a series of optional params so that we can avoid future API changes
* if we add a new generation option.
* - Add a GalleryStatus object return for GalleryUrlGenerator::init
* - Move from returning GalleryStatus::success() to returning null
* on success so that we can avoid thousands of calls to success()
* and isError() on every request (and avoid loading GalleryStatus at all
* unless we need it.
* - Rename save to _save in GalleryEntity child classes,
* GalleryEntity::save calls $this->_save then sends event (ensure event last)
* - Change Arguments to GalleryUrlGenerator::init to init($baseUri, $embedUri,
* $embedSessionString) since GalleryEmbed params will be changed too
* And add optional forceG2Base to various UrlGen methods
* - Remove unused GALLERY_PERMISSION_ITEM_ADMIN flag. There's a patch
* for it here: http://tinyurl.com/9l9wz
* others may depend on this constant, so we have to do it with an API
* change.