Thoughts/questions about PhotArk architecture

[Phillipe Ramalho <ph...@gmail.com>]

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

Re: Thoughts/questions about PhotArk architecture

[Phillipe Ramalho <ph...@gmail.com>]

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 <lu...@gmail.com>wrote:

> On Mon, May 31, 2010 at 1:38 AM, Phillipe Ramalho
> <ph...@gmail.com> 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

Re: Thoughts/questions about PhotArk architecture

[Luis Fernando Carmo <lu...@gmail.com>]

On Mon, May 31, 2010 at 1:38 AM, Phillipe Ramalho
<ph...@gmail.com> 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