User Tools

Site Tools


po_devel_changes

This is an old revision of the document!


Development Plans

If you wish to request a new feature, please add it to the bug tracker. If there is a feature listed here with an accompanying bug number, please add your vote of support so it may get done sooner. Or better yet, undertake it yourself. :)

If you really want a certain feature implemented, you may need to scratch our back a bit to bump it higher on the priority list..

Features already present in the development tree

These features currently exist only in the development tree. As they are backported, they will disappear from this list and appear on the Stable Changelog page, where they will accumulate until the next release. If there is something you wish to get backported sooner rather than later, leave comments in the appropriate bug ticket or on the mailing list.

A demo site running the latest -devel code can be found at http://po.shaftnet.org/po-devel-demo/. This is not considered stable enough for production, and as such may have unknown bugs and incomplete features. That said, the maintainer runs his personal site (http://www.shaftnet.org/po/) on the same code, so any problems get sorted out quickly.

Changes from the -STABLE codebase (v2.36.x)

  • [misc] Upgrade the IE7 compatibility library to v2.0b3
  • [misc] Upgrade wz_tooltip library to v5.2
  • [add] Add 'bulk rotate' support. [#359] [#373]
  • [misc] Further refactor some of the import code.
  • [misc] Use SQL 'ILIKE' instead of regexp matching for search strings.
  • [add] Admin user can change a user's email address/username [#347][#196]
  • [add] Basic out-of-band logging support. [#221]
  • [add] Log all memcache operations
  • [lang] Simplify the i18n resources a bit.
  • [misc] Add generic “run a simple DB query and cache it” functions.
  • [misc] Simplify the photo/version id sanity checks.
  • [misc] theme_display_photo() doesn't take image size any more.
  • [misc] Clean up the rating code on the main photo page.
  • [misc] Move to pg_fetch_all() where possible.
  • [del] Delete all image-based searching code. Will return one day.
  • [sql] Convert all latitude/longitude fields to numeric types.
  • [sql] Delete a few unused DB views.
  • [misc] Location profile page now differentiates between photos you own and all photos in the system.
  • [misc] Have the installer test for memcache support.
  • [misc] Location add/edit now uses the fancy latitude/longitude parsing code.
  • [misc] Hide keywords/views on the photo tooltip info if it's empty.
  • [misc] Migrate more queries to take advantage of memcache.
  • [fix] Allow guests/etc to see technical image details.
  • [misc] Consolidated photo and version import into one function.
  • [misc] Added a vastly more efficient way of fetching random photos.
  • [add] Serialize out all import jobs to the database, decoupling the actual importing from the submissions. This will let us parallelize imports across multiple processors in the near future. 167
  • [add] Remember per-folder/album sort order and view type.
  • [add] List available image sizes. (will improve this later)
  • [add] Generate a full-size image from RAW imports. 7
  • [add] Initial background image import/processing worker. 167
  • [add] Pretty-URL the folder search too.
  • [misc] Vastly speed up searching for “multi-word matches”
  • [fix] Fix “”““excessive””“” quotation in tag searches.
  • [add] Generate additional preview-size images (350,700,1050)
  • [fix] Changing folder order from folder search page now works.
  • [misc] Imports are now two-phase; first the metadata is committed then the files are scaled/imported. This greatly reduces the time we hold transactions open, and allows imports to be parallelized to a much greater extent.

Current to-do/wish list, in no particular order

This list consists of longer-term projects/goals which are generally made up of sub-tasks. All of these tasks are listed individually in the bug tracker. Please make new feature requests there.

This list also reflects the personal interests of the developers. There is no set schedule or roadmap for feature implementation, but incentives are certainly appreciated.

Additional themes

We have the original Aqua and a dark derivative (Blackwater) of it, but more, different, themes would be nice. And while we're dreaming, it would be quite nice to move to a proper templating system (such as Smarty), but that is quite a lot of work for lil' ol me to do.

More UI work

There are lots of little enhancements to the UI I'd like to make, including the use of DHTML to speed up page loads (for the photo page tabs in particular), easy selection between multiple photo versions and image sizes, a scrollable list of images on the photo display page, “what's new” lists, a better system for bulk-tagging images, nicer photo slide frames, etc, etc…

Better RAW Support & Image manipulation pipeline

Ideally we could adjust the RAW settings on a per-image basis, and allow regeneration based on the stored settings. There's actually a lot of work involved here. 6 It would also be nice to allow users to add custom image processing pipelines. (eg sharpen,crop,add a custom border,shadow,user-specified text…).

There are many ways we can improve both the speed and functionality of Photo Organizer's searching features, including caching of results, allowing searches of every stored field, and sub-searches. 89 239

Dynamic Albums

Allow users to create 'virtual' albums that are tied to a particular search query. Any searchable field should be allowed. An example of how this would work is the current browsing by tags.

GIS/Geospatial Support

Specifically, integrate PO with PostGIS, and use it to add a whole bevy of features – “locations” can be polygons and location/distance/area-based searching becomes nearly trivial. Additionally, integrating with additional Geospatial applications would be much easier.

Content-based searching

Theoretically, Photo Organizer supports bits of this already, but lacks a search backend (and integration instructions) to actually perform “find images like this one” searches. 100

Photostreams & RSS

We already have the means to pull up images between arbitrary date ranges, so all that's left is building cool features on top of this – RSS feeds and pseudo-albums based on date ranges come to mind. 176

External APIs

Implement some sort of RPC mechanism (XMLRPC/SOAP/JSONRPC/whatever) that allows third-party software to call into PO's backend. There's a lot one can do with this sort of API. (“Give me ten random highly-rated images from user X's collection” “give me all the technical info about this photo” “give me an embedable image+url that I can inline into some CMS system”)

New Permission Model

The current permission model is insufficient for many use cases. 8 245 Ideally, we'd be able to specify access rights on a per-user basis, not the current “public,clients-only,private”. This not particularly important for a single-user system, but makes a huge difference for larger deployments that have well-defined roles. (See New Permission Model)

Database Abstraction Improvements

While Photo Organizer will most likely remain PostgreSQL-dependent, we need to migrate to an abstraction layer (eg PHP:PDO) so that we are not tied to using PostgreSQL's bindings. In the process, we will rewrite all transactions using lazily-bound parameters to completely eliminate any possiblilty of future SQL injection problems. 11 Additionally, there are other database-level cleanups that need performing. 201 204 210. This will require PHP 5.1.0 or newer.

Additional Authentication backends and single-sign-on

We have the means to authenticate against an external system, and sample LDAP and external database support. Down the line, we should look into tying into a single-sign-on solution like OpenID and/or integration into CMS systems (eg Drupal).

po_devel_changes.1227071457.txt.gz · Last modified: 2008/11/19 05:10 by pizza