>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. That's pretty much it, but what you call "bookmark aggregator" would be the same as a regular album with description, cover and everything else. The most important thing I would like to change is the way a picture is added to an album. That's is why I have suggested an ImageLoader for each image source service (picasa, flickr, filesystem, etc). The album itself shouldn't do no more than hold info about it and a list containing location strings to the pictures, and pictures would be added using the Gallery interface: Gallery.addPicture(String album, String picture). A location string could be a URL like, e.g. "picasa: http://picasaweb.google.com/!user=phillipe"; (a private image), and the PicasaImageLoader would be responsible for loading the image using the correct login info for the user "phillipe", which my be fetched from somewhere else, maybe from security service, I'm not sure. This would allow the album aggregator consumer to resolve and load the album images later. I'm also not sure if Album classes implemented to expose albums from specific providers like Picasa and Flickr would be the best approach. Instead, a AlbumLoader could be used, which would load every info from a provider's album into an Album object, and return this object to the user (probably the gallery). Well, this is just an idea, but no matter how it loads the info from the provider, it would be nice if it could notify the gallery when a picture is added or removed. Phillipe Ramalho On Mon, May 31, 2010 at 3:26 PM, Luis Fernando Carmo <[email protected]>wrote: > 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 > -- Phillipe Ramalho
