incubator-photark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adriano Crestani <adrianocrest...@gmail.com>
Subject Re: PhotArk Gallery API
Date Fri, 11 Jun 2010 05:00:42 GMT
Hi Luciano,

 - How to support this in a file system based gallery ?

We could unify the gallery impls and support only JCR as the main
impl. Filesystem would only be a AlbumService which is responsible for
loading the images from that specific source (filesystem) and
subscribing them in the JCRGallery. This way we could enable a gallery
that supports images from many different sources, not only filesystem.
I wonder how we can keep the original source in sync with the PhotArk
gallery, we could provide an API so the user would tell PhotArk
when/what to sync.

By the way, how about using Lucene instead of JackRabbit to store the
images and their info/tag? JackRabbit uses Lucene after all. Is there
any extra JackRabbit functionality that Lucene does not support? This
way we could integrate the image/album/tag repository with the search
index.

 - 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
again?

Subscription would only tell the gallery where the image is, then
later the user can add it to one or more albums, or set a tag to it
and etc. The image visibility would be up to the UI impl, PhotArk will
be mainly responsible for providing different ways to aggregate and
expose images, whether as albums, tags or search results.

 - 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.

You are right, we would need an unique id instead of just the image
name, any idea?

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
branch.

I can help, mainly on the backend, I'm usually not the UI guy :)

Best Regards,
Adriano Crestani

On Thu, Jun 10, 2010 at 11:00 PM, Luciano Resende <luckbr1975@gmail.com> wrote:
> On Thu, Jun 10, 2010 at 12:46 AM, Adriano Crestani
> <adrianocrestani@apache.org> 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
> again?
>  - 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
> branch.
>
>>  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
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>

Mime
View raw message