2014-09-05 14:03 GMT+02:00 Justin Edelson <jus...@justinedelson.com>:
> Hi, > > On Fri, Sep 5, 2014 at 3:50 AM, Carsten Ziegeler <cziege...@apache.org> > wrote: > > 2014-09-04 21:28 GMT+02:00 Justin Edelson <jus...@justinedelson.com>: > > > >> Hi Carsten, > >> I see that this issue was closed, although it isn't clear to me why. > >> > >> I've got the basics of CRD working locally and wanted to get some > >> feedback on the approach before working on the U part. > >> > >> > > I already implemented it back then, together with tests :) > > Then I'm utterly confused as to what we're talking about. I thought > you were suggesting to have the merging ResourceProviders optionally > implement the ModifyableResourceProvider interface. I don't see where > this was done. > > :) Yes I was talking about that, what I meant is, I already implement this as part of SLING-3420 which then started this whole long endless discusssion in that issue, I reverted my commit, changed the title of that issue and we went with the compromise mentioned in that issue. So I implemented this once, the code is still in some revision (rev 1572893 is the last one with the code) and can be pulled from there. A fresh implementation is of course as good, in that case we can just pull the test case from rev 1572893 Carsten > Justin > > > > > Carsten > > > > > >> Justin > >> > >> On Thu, Sep 4, 2014 at 11:07 AM, Carsten Ziegeler <cziege...@apache.org > > > >> wrote: > >> > Ok, here we go: > >> > > >> > https://issues.apache.org/jira/browse/SLING-3420?focusedCommentId=13914543&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13914543 > >> > > >> > And as I said, it's optional - and from that description you see which > >> > decisions a UI (or any client) would need to take (ok create and > update > >> are > >> > the same post operation). And you definitely don't want to code this > over > >> > and over again, especially as you would need to do additional round > trips > >> > to check whether a resource exists at the first search path. > >> > > >> > Carsten > >> > > >> > > >> > 2014-09-04 15:07 GMT+02:00 Carsten Ziegeler <cziege...@apache.org>: > >> > > >> >> Hi Justin, > >> >> > >> >> 2014-09-04 14:12 GMT+02:00 Justin Edelson <jus...@justinedelson.com > >: > >> >> > >> >> On Thu, Sep 4, 2014 at 5:04 AM, Carsten Ziegeler < > cziege...@apache.org> > >> >>> 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? > >> >> > >> >> > >> >> Just because you don't need them and don't want to expose them. I > agree > >> >> that they don't hurt, but why exposing them if you don't need them > but > >> >> just want to register your own merging at some path? > >> >> > >> >> 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. > >> >>> > >> >>> +1 > >> >> > >> >> > >> >>> > > >> >>> > 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. > >> >>> > >> >> > >> >> I think it's somewhere very well described in an issue. I need to > dig it > >> >> out. > >> >> > >> >> Carsten > >> >> > >> > > >> > > >> > > >> > -- > >> > Carsten Ziegeler > >> > Adobe Research Switzerland > >> > cziege...@apache.org > >> > > > > > > > > -- > > Carsten Ziegeler > > Adobe Research Switzerland > > cziege...@apache.org > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
