Programming - - By Harry Fuecks

PHP / Web Application Integration

I forget how I ran into this document now and can’t even tell you who the author is (hopefully they’ll step forward) but it’s an interesting read anyway: Aspects of the integration of two or more web applications (application/pdf). Found the link a while back, via one of the Gallery forums / mailing lists, thanks to a chance result searching for something entirely different on Google.

Anyway – memory loss aside – this is basically a short “research paper” written by one of the Gallery2 development team on how to do web application integration. In case you were wondering Gallery is a (perhaps the most) popular PHP image gallery application. Gallery2 is a complete re-write and was released last autumn (./ announcement here).

Returning to integration, this is area which has yet to be well solved IMO, either in PHP or other web platforms. The basic requirement often stems from “How do I provide my sites visitors a single signon to my forum / wiki / blog / gallery etc.?”.

The gallery2 paper identifies the following key “aspects” for integrating web applications (the selection of items has a PHP-specific slant but believe it’s still broadly applicable to any web platform);

  • Master-Slave relationship and Communication
  • User and Group management
  • Session management
  • Authentication
  • URL generation
  • Visual Integration
  • (Permission Management)
  • Controlling Access
  • Search and other API interfaces
  • Namespace Collisions
  • Environment

Will let it speak for itself. Really this document now needs expanding with more detail and proposals for ways to solve this stuff in a generic manner (if that’s at all possible) that could be applied to any (PHP) application.

In practical terms, another way to look at web application integration is where to do it, as in what layer? That pretty much boils down to;

  • At the data: e.g. hack App Y’s signon logic to use App X’s “users” table. This often starts out looking like the easiest way to go but, in practice, may lead to having to re-write (or copy / paste) significant parts of App Y and means you need to track your hacks. Every time I’ve ever gone here, reached that point of “Would have been less work to write my own from scratch”.
  • At the code: APIs, smart includes etc. This is generally the way to go I guess but requires application development teams to think out of the box a little and consider how and where other applications could plugin with theirs. Have seen this done many different ways in PHP, from fudforums fudapi.inc.php (an includable PHP script containing functions like fud_fetch_full_topic) and the Horde framework’s “COM” to Serendipity’s embed “mode” and dwBliki. Really this topic needs a long, long discussion, which I’m going to avoid.
    But while I’m here, on a semi-related note – Scarlet (en) a dependency injection container for PHP. This is not the only PHP DI implementation BTW – will have to see what Pawel has to say about his on Friday. Meanwhile Jeff has something brewing.
  • At the HTML: such as Sitemesh way (or PHP Mesh – capture and merge your HTML server-side. XSLT might also apply here. Also relatively easy but also easy to break I guess.
  • …and one more I guess – Greasemonkey – push the problem onto the browser.

Anyway – judging by results, the Gallery team certainly have some lessons to share.

Ending on a vision thing: how about we make 2006 the year we really nail PHP app integration?