On Sun, Jan 30, 2011 at 3:40 AM, Subash Chaturanga <[email protected]> wrote: > Hi all, > > The jira [1] I work on adding UI support for remote album subscription, I > came across with some problems with the proper, formal way of managing > dependency as Suhothayan mentioned. > > Currently I have two services which facilitates remote album > subscription, PicasaSubscription and FlickerSubscription inside > photark-picasa and photark-flicker packages separately. And* I have jcr > dependencies in both photark-picasa and photark-flicker poms*. So in order > to change that, I thought of the following format. > Also currently *PicasaSubscription and FlickerSubscription services shares a > common interface called SubscribedAlbumGallery*in > org.apache.photark.services.gallery. > > *1. Rename SubscribedAlbumGallery to RemoteAlbumSubscription and move the > interface to org.apache.photark.services.album.* > *2. Move PicasaSubscription and FlickerSubscription classes to a new package > org.apache.photark.jcr.security.albums.subscriptions. * > > Then there wont be any jcr dependencies inside photark-picasa and > photark-flicker. > Is this fine ? any suggestions ? > > [1] - https://issues.apache.org/jira/browse/PHOTARK-62 > > > Thanks in advance > /subash >
You should think separation of concerns here. The specific modules that deal with remote albums (subscriptions) should know how to handle the specifics of the album providers (e.g picasa, flickr, etc). Then we can have a subscription manager in the JCR repository that, once you create a new subscription will use that provider specific component to read the remote album and store locally, and not the other way around, where the provider would store data in the JCR. -- Luciano Resende
