[Melbourne-pm] Picture Management API

Scott Penrose scottp at dd.com.au
Tue Mar 14 16:07:33 PST 2006

Thanks everyone so far for your feedback. What I am doing is starting  
with analyses of most perl API and a few applications - covering most  
things on CPAN and more.

On 14/03/2006, at 17:31, Gerard . wrote:

> I would want it to be just like flickr.com, with some slick AJAX  
> features :)

What I am trying to do has no interface at all. It is purely all the  
backend - resize, rotate, get information, organise, group together  
into albums, search etc.

Then once you have the API you can do the following:

* Write a GUI - give you cool access to those features, very easy
* Write a Web Program - that has flickr / AJAX like features.

The DBI of Albums

If you know DBI, this is soft of a summary for what I want.
In theory then if we write a cute GUI then if someone wants to manage  
their code with Gallery Remote or FLICKR or Local Disk or common  
MySQL type systems - they just change the driver and it all still works.

The Document

The big thing my document is covering - should have it out in draft  
tomorrow - is reviewing the requirements, limitations of existing  
systems. As an example, I have found some modules (like  
Apache::Gallery) which just manage the images and produce XML - so  
that I can completely separate the HTML & JS & AJAX et al from the  
images, resizing etc.

But even that has one step not far enough removed... Ideally the code  
would look like this...

	Gallery API		
		- Manage the files, rename, delete, metadata, search, resize,  
caching of thumbnails etc

	Gallery API to XML
		- Find a nice XML format for describing Gallery - there is already  
some out there
	 	  and convert between

	Apache Gallery Module
		- Manage the URLs - so you can turn a URL into an Album or Picture
		- Manage the actual pictures - so you get a view of any size of image
		- via Apache - manage the access control
			This is one of those important ideas when it comes to reuse of code
			Web, Apache and Security - for example, you may want to make it
			so that only logged in users can see the full size version - or  
the version
			without a watermark.
			You should use Apache to do this - not your own security.
			However - in Apache, you pretty much require URLs to do that.
			This needs to be considered

	Apache CGI or XSL or JSP or PHP or ...
		- Provide the interface
		- Turn the XML into XHTML 2 or XHTML 1 or HTML 4
		- Add JavaScript, call back AJAX etc

Now of course - that is just one model. By doing the break up above  
we can reuse the components like this...

	* Write a Catalyst Application - with NO Apache !!!
		- Reuse Gallery API as is
		- Reuse Gallery API to XML as is
		- Reuse the XSL from the last stage - probably as is

	* Write a GUI that views the system directly from the disk
		- Reuse the Gallery API as is

	* Write a GUI that runs remotely - maybe even a Java Applet
		- Reuse the Gallery API as is
		- Reuse the Gallery API to XML as is
		- Reuse the Apache Gallery Module as is
		This allows an object to deal with the data by only doing REST
		style XML requests.
		Of course this is also the basis of AJAX so you get even
		more reuse if you want to build a complicated Client side AJAX
		based API

What I am describing here is nothing new in the application world,  
but we don't develop like that in the web world.

But what I want here is just step one - the Gallery API.

The rest will follow naturally :-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.pm.org/pipermail/melbourne-pm/attachments/20060315/74b8581e/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://mail.pm.org/pipermail/melbourne-pm/attachments/20060315/74b8581e/PGP.bin

More information about the Melbourne-pm mailing list