incubator-photark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luciano Resende <>
Subject Re: PhotArk Gallery API
Date Fri, 11 Jun 2010 03:00:26 GMT
On Thu, Jun 10, 2010 at 12:46 AM, Adriano Crestani
<> wrote:
> Hi Luciano,
> The rest proposal looks good, some comments/questions below.
> Should we still keep the current model where images belong to a single
> album? Phillipe's scenario, where he describes aggregated albums
> referencing pictures that do not belong to them, would not work as
> expected if we keep this approach, because a deleted album might
> affect the contents of another album. I would also vote for a model
> where pictures belong only to the gallery and albums only referencing
> them. If we follow such model, the following rest APIs would need
> changes:

So, I have entertained this approach as well, (and this is the
approach taken by Flickr).
My view is that this brings some complications:
 - How to support this in a file system based gallery ?
 - How album subscriptions work on this scenario ? Is it just going to
be "lost" under the "all images" photo stream ? Do we force it to have
an associated tag, which really then becomes the concept of albums
 - We have to come up with all sorts of unique id generation to
identify photos, as without the boundaries of albums, you can have
file name collisions when uploading two photos, with same file
DSC0001.jpg when they actually two different photos.
 - I'm also not sure how big the impact on the user experience and in
the UI itself.

I'm also not sure if we can't really still provide all tag support on
top of current album based gallery.

Having said that, if others think this has more flexibility and would
be a better approach... and if someone is willing to help on the UI
side, I'm willing to start moving to that direction on the REST

>  Image Operations
> – Retrieve a specific image from gallery
> GET http://localhost:8080/photark/gallery/dsc123.jpg
> – Add new image to gallery
> POST http://localhost:8080/photark/gallery/dsc123.jpg
> – Update new image to gallery
> PUT http://localhost:8080/photark/gallery/dsc123.jpg
> – Delete an image from gallery (this should consequently remove the
> image reference from all albums)
> DELETE http://localhost:8080/photark/gallery/dsc123.jpg
> – Retrieve a list of image references for an album
> GET http://localhost:8080/photark/gallery/<album>/images
> – Add new image reference to album
> POST http://localhost:8080/photark/gallery/<album>/dsc123.jpg
> – Add an image reference from album
> DELETE http://localhost:8080/photark/gallery/<album>/dsc123.jpg
> Note: with this APIs the user won't be able to be aware of pictures if
> they are not in an album, but if we want to, we can also add
> – Retrieve images from gallery
> GET http://localhost:8080/photark/gallery/images

If images are uploaded directly to "gallery", this proposal won't work
and we need to handle collisions with something like :

GET http://localhost:8080/photark/gallery/124324223

where 124324223 is a unique (and possible short) identifier for dsc123.jpg

>  Should we use http://localhost:8080/photark/gallery or
> http://localhost:8080/photark/gallery/albums/
> +1 for http://localhost:8080/photark/gallery/albums/
> Do we ever need to retrieve a list of albums with full data ?
> Do you see any reason to not to?

If we still have albums, I believe that the most common scenario is
that you retrieve a list of albums, and then show the contents of a
given album. Not sure if you want to have the ability to return the
content of all albums, which might be big. Having said that, it should
be pretty easy to provide another endpoint to output the full content
of the album, but it probably should not be the default behavior.

Luciano Resende

View raw message