[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 :-)
Scooter
-------------- 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