On Mon, May 31, 2010 at 1:38 AM, Phillipe Ramalho <[email protected]> wrote: > Hi everyone, > > I have been going through PhotArk code lately and I have some questions > about its design: > > 1. PhotArk architecture guide states that a gallery is: "a facade that > enables application to interact with the different types of albums of a > gallery" [1]. > > There are currently only two gallery implementations: filesystem and jcr. > But actually there is no way I can have a gallery that supports multiple > types of albums, e.g., one jcr and one filesystem album. Is that correct? > > 2. What exactly is the concept of an album? Architecture guide says: > "abstracts > the operations available for the different types of albums. This should be > extensible to allow users/developers to plug support for other types of > albums." [1]. It doesn't say "Album", but instead it says "Album Service", > which for me shouldn't be considered the same thing, but based on the source > code, Album interface holds operations used by an Album and what PhotArk > guide calls Album Service. > > Well, for me, an ideal virtual album is something that aggregates a bunch of > pictures, maybe specifying the order, and holds a bunch of information about > that aggregation (description, cover picture, etc). I said "virtual", > because virtual albums allow us to do some extra things as having different > albums containing the same picture and pictures coming from different > sources. E.g., in my gallery I could have a picture (hosted on flickr) from > my vacation which was taken in 2008 and I could add it to two different > albuns: "Vacation" and "2008 Pictures", I could also have another picture > (hosted on picasa) from another vacation and added to the same album and > under the same gallery. > > So I would say that an "Album Service", which I would like to call something > like "ImageLoader Service", should only be responsible for loading an image > from a specific source (jrc, filesystem, flickr, etc) and return it to the > gallery. All the user would need is to add a picture to a gallery using a > location string, and based on it, the gallery service would delegate the > image loading to the corresponding ImageLoaderService when that picture is > requested from the gallery. In the end, an Album (not album service) would > only hold info about that album and a list of strings, which are location > strings that point to the album's images. > > This design also centralizes the image add/deleting on the gallery side, > allowing it to also delegate the event of add/deleting to extra pluggable > components (like search) which would like to be notified when such events > occurs. > > Hey! Comments, suggestions and questions will be very welcome :) > > Kind Regards, > Phillipe Ramalho > > [1] - http://incubator.apache.org/photark/photark-architecture-guide.html >
>From what you are describing, there seems to be three types of albums : - Local (stored in the JCR, FileSystem, etc) - Virtual (hosted in a different album provider such as Flickr, Picassa, etc) - and a third category, more like a image bookmark aggregator, where photos/images don't come from any specific album (see http://creative.ly/). I guess this is more like a "local album" where a user don't always update images from a local hard disk, but it only add a "link" to a photo/image available in the world wide web. My GSoC project is handling the "virtual album" scenario, but I didn't think about this new option... but I guess I can start thinking about it and see if this new scenario would fit the time/schedule for my project. -- Luis
