+1 for an AlbumSubscriptionManager, it's easier for the user to just add a new jar to the classpath containing the new album impl and let the AlbumSubscriptionManager discover. The user will be able to just download the album jar and plug it in by adding a reference to the META-INF/services folder. Well, I at least think it's easier than editing the composite file. I hope this is what you want, let me know if I didn't get it right ;)
and +1 for supportedOperations method. It will allow the any photo gallery UI to generate clearer user interfaces that will know whether the user can or cannot do certain operation. Adriano Crestani On Mon, May 31, 2010 at 6:14 PM, Luis Fernando Carmo <[email protected]>wrote: > On Mon, May 31, 2010 at 12:14 PM, Luis Fernando Carmo > <[email protected]> wrote: > > I have been looking into how to handle Album Subscriptions, and how > > that could follow the current project design. Two things commes to > > mind initially, one is to have a AlbumSubscriptionManager class that > > would be a reference in the GalleryService, and this class would be > > responsible for allowing some extensibility/plugability and discover > > the supported album types... another way would be to have specific > > references for each supported album implementation (e.g Flickr) > > injected into the GalleryService... > > > > Thoughts ? > > > > -- Luis > > > > Another thing that comes to mind is that, when subscribing to a album, > you might not be the owner of the album and can't really do all types > of operations to the album such as adding new photos. Should we > modify the current Album API to provide a list of supported operations > ? Anyway, for now I'm planning to throw UnsupportedOperation exception > when some of these methods are invoked in a subscribed album. > > -- Luis >
