Hi Andriano,
On Sat, Nov 13, 2010 at 12:43 AM, Adriano Crestani <
[email protected]> wrote:
> Hi Subash,
>
> It's something like that, but more flexible and transparent to the user.
> Flexible: new remote albums might be added without changing the code
> implementation, so "if (type.equals("flicker")..." is too hardcoded for
> that.
As far as I understood on this discussion, different types of albums must
not just put directly inside root. So you what you meant by "too hardcoded"
means, to put all remote albums inside "/remote/" with out further
classifying.
> Transparent: the user shouldn't notice the difference between an
> AlbumAggregator and any other type of Album implementation, ideally, the
> user should only deal with Album API when dealing with albums.
>
> I'm working on a new low level API for rest branch, which will use tagging
> system instead of album. It has been discussed before, I think it was first
> raised by Phillipe or Luciano, once it's done, photo aggregation should be
> straightforward. I hope to get some running examples soon.
>
> Regards,
> Adriano Crestani
>
> On Thu, Nov 4, 2010 at 6:31 PM, Subash Chaturanga <[email protected]
> >wrote:
>
> > Hi Luciano,
> >
> > Here I am attaching a patch (for the simplicity to understand, this
> doesn't
> > have all my previous changes).
> >
> > This has the implementation of an AlbumAgregator ( as this is an attempt
> to
> > understand what you meant, I didn't change AlbumAgregator in photark
> > package.Hence I just created it in photark-jcr package temporary) and
> some
> > related changes in JCRAlbumImpl and JCRGalleryImpl, from which I
> understood
> > from you and Andrino's conversation.
> >
> > Is this what you meant ? As this is not fully completed, I didn't updated
> > the JIRA.( Because if I have mis understood what you said, it is no point
> of
> > going in this approach further. )
> >
> >
> > Regards
> > /subash
> >
>
Regards
/subash
