On Mon, Jan 31, 2011 at 10:28 AM, Luciano Resende <[email protected]>wrote:
> On Sun, Jan 30, 2011 at 7:04 PM, Subash Chaturanga <[email protected]> > wrote: > >> > >> 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. > > > > > > +1 , will do. > > > > Because currently I have two provider specific service components which > do > > both read and store albums in JCR, by themselves and UI talks to them > > separately. So adding a subscription manager and UI will only call to > that > > manager and he will read the albums from a provider and store them. I > hope I > > got your idea correctly. > > > > > > Looks like we are in the same page. BTW, I'm trying to get the same > services in place in the REST branch, hopefully I can get that in the > next day or so and it might be of some help. > Hi Luciano, I have changed my patch as you said by giving the responsibility to a subscription manager which helped me to make the front end less complex and seems like its fine. And I had some other minor issues after that and now I have resolved them. When you are free, can you please try the latest patch[1], and see whether this is, as you expected . Then I can do further changes, with your feedback. [1] - https://issues.apache.org/jira/secure/attachment/12470269/uiSubscriptionWithNewStructureCompleted_upd2.patch > -- > Luciano Resende > Thanks /subash
