(June 28, 2007)

When I reviewed my photosets here, I got surprised to find them offline. The culprit was traced to Google's ever-changing DOM/XML output. Yep, until now, they're still changing it. This means I had to update my image gallery engine to be able keep up. This also provided me an opportunity to significantly speed up the engine. So I sat down and did some modifications. I came up with 2 updated versions:

1. One with DOM/XML support.
2. Another one without DOM/XML support. I did this because my webhost has yet to enable this feature in its PHP installation (as of this writing), but they said they'll be turning this on soon.

Both versions, however, now enjoy full session caching support. This significantly speeds up a user's browsing experience. Well, actually, the experience gets faster and faster as his/her browsing session wears on. Admittedly, from my personal experience, however, it appears that Google (or PicasaWeb) passively delays GData and image file requests - or maybe this is just an effect of its load-balancing technology. Understandably, they have to throttle GData and image requests so they don't get flooded by external threads that do not make use of their ads. Whatever the case, these new versions now only request for GData once initially, per album, per user session, per browser. After getting the GData, the image gallery engine caches this in session variables. Successive page requests effectively bypass asking for GData needlessly again - unlike in the previous version, so only the image files get requested - and probably cached by your browser depending on its intelligence. Of course, it is important to first call a session_start() to enable PHP support for sessions, especially in stand-alone applications of these image gallery versions.

I kept the old version for legacy safekeeping, just in case. The helper function found in ldigs_function.php, however, has been updated to accommodate DOM/XML requests.

Zoom in this document to find the updated instructions set below.

Sample implementation of an updated version: http://www.loloyd.com/blog/nso_bike_rack_gets_devirginized

(April 16, 2007)

Finally, I am able to finish, with satisfying results, my PHP Image Gallery with Slideshow fused with the Picasa Web Google API. Now, I can make my web-based photo albums all centrally available from my website. And with Google's mindset of ever-expanding space allocations, I can rest my butt and wallet. As of this writing, my Picasa Web account has a 1 Gigabyte limit... and counting. Thank God, for Picasa Web and Google API.

Just follow my simple instructions, and you can use this API code too for your own purposes - on your own websites, for free!

To maintain the initial featureset of my original image gallery, I had to make a few key adjustments. One of these is on putting my slideshow formation function onto a separate file. This was necessary in order to commit to the somewhat unique featureset of my LD TechnoLogics Image Gallery With Slideshow Fused With Picasa Web Google API:

1. Ability to present multiple photoset albums simultaneously in a single page, albeit with some known quirkiness. The quirkiness can be described as synchronous image zooms, i.e., zoom in on one image from one album and the other albums zoom in too on that specific image number if it exists.
   

   You can try and see this in action by zooming in an image from the page http://www.loloyd.com/taxonomy/term/photosets. Zoom in on a single image from any album on that page, and you will note that the other albums will also show an image with the corresponding image number.

2. Slideshow functionality - hey, not all image galleries can boast of this feature. :-D But since I'm releasing this as an open-source freedom-use API, now all other image galleries potentially can! :-D
3. Relative ease in hackability/configurability/modifiability.
4. Custom primitive XML parser for the Google API feeds!
   

   Heck, this may even perform faster than that built-in xml_parse PHP function (it does so from my tests) and I can speculate why. My custom parser is made up of simple and light-weight functions that target specific strings.

5. Portability. Works standalone. Works plugged in CMSs or CMS frameworks - especially Drupal (grin).
6. Usual yada-yada, i.e., small (around 10 kilobytes), fast and efficient.

(Timeless information)

Sample implementation: http://www.loloyd.com/photosets/2007_iriga

Requirements and Instructions for Use

Important Note: This code has been released under the usual terms of GNU/GPL. Although not necessarily expected, a back-reference or trackback to my website http://loloyd.com/ is requested and very much appreciated.