Hi Carsten,
On Thu, Sep 4, 2014 at 5:04 AM, Carsten Ziegeler <[email protected]> wrote: > Thanks for the work, Justin! > > I'm wondering if we really should enable both ootb merging providers. If > users want to have their own merging picker, they end up with the default > providers being registered and disabling them requires a configuration with > an empty root. Why would they need to unregister the default ones? The only reason I can think of to do this would be to reuse the same base path but with different semantics, but IMHO this _should_ require jumping through the extra hoop of disabling the default. What I see as more common is the creation of _different_ base paths, e.g. /mnt/mycustomthing. > > I wasn't wrong to enable the merging provider in previous versions as this > was the only one. With several potential providers, this is different. > Therefore I think we should disable both by default - and bump the version > to 2.0.0. > > In addition, the ResourceMergerService is now a little bit questionable - > at least some of the methods are. So we should think about it. I agree, although I hadn't gotten around to starting that thread (and it is IMHO orthogonal) :) I don't totally understand the point of this service. Does anyone actually use it? I'd like to just deprecate it. > > And finally I want to add optional CRUD support :) Could you create a wiki page with the conclusion of your discussion with Alex listing the various CRUD actions and what they actually do to the merge sources. Please do keep in mind that there can be N number of merge sources at this point. Regards, Justin > > Regards > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected]
