You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Michael Dürig <md...@adobe.com> on 2014/09/12 21:01:27 UTC
Re: Experiment versioning path based on Sling search path
+= DL-dev, as I think this topic is important enough to have a broader
audience.
Some random food for thoughts re. S2:
- What about ACLs on this v1 node? These will still apply but be
invisible through the wrapper.
- What about Oak's exception messages containing paths?
- Did you think of versioning and the version store? That one will
probably contain the wrong paths unless we also apply remapping there.
- JCR has the PATH property type. Do we need to map those values? All?
Some? Which?
- Tooling and management will still be using the unmapped paths.
- Query is not just about mapping the queries. Its also about undoing
the mapping in the query results. Furthermore you also need extend the
mapping all the way through the QOM, which is exposed through the API.
Michael
On 12.9.14 11:13 , Alexander Saar wrote:
> Hi Tim,
>
> Just had a look at your wiki pages (especially [1]). To me it sounds
> like S2 is currently our best shot. Since you started already with a POC
> would it make sense that you try to finish a first quick version that
> can be used for verification? What do you think would it take in terms
> of effort to get to a first working PoC?
>
> Would also love to hear if anyone has objections against this approach
> or sees potential problems already.
>
> Thanks
> Alex
>
> [1]
> https://wiki.corp.adobe.com/display/marketingcloud/Implementation+at+JCR+level
>
> From: Timothee Maret <tmaret@adobe.com <ma...@adobe.com>>
> Date: Donnerstag, 11. September 2014 17:20
> To: Carsten Ziegeler <cziegele@adobe.com <ma...@adobe.com>>,
> Bertrand Delacretaz <bdelacre@adobe.com <ma...@adobe.com>>,
> Ian Boston <boston@adobe.com <ma...@adobe.com>>, Felix
> Meschberger <fmeschbe@adobe.com <ma...@adobe.com>>, Marc Pfaff
> <pfaffm@adobe.com <ma...@adobe.com>>, David Bosschaert
> <bosschae@adobe.com <ma...@adobe.com>>
> Cc: Philipp Koch <pkoch@adobe.com <ma...@adobe.com>>, Michael
> Marth <mmarth@adobe.com <ma...@adobe.com>>, Alexander Saar
> <asaar@adobe.com <ma...@adobe.com>>
> Subject: Re: Experiment versioning path based on Sling search path
>
> Hi Carsten,
>
> On 9/10/14, 14:47, "Carsten Ziegeler" <cziegele@adobe.com
> <ma...@adobe.com>> wrote:
>
> Hi Tim,
>
> I came to a simular conclusion after finding literally thousands
> of hard
> coded paths in the AEM code base.
> Some of them might be handled by hooking into some of the existing
> services (like taglib inclusion, link rewriting), but still it's
> a lot.
> And customers probably have similar code as they copy our "best
> practices". Apart from taking a lot of time to get all of this
> right, I
> see the problem that we miss things. And both together seem barely
> manageable for us.
>
> I've discussed a different approach (wrapping the whole JCR api
> on the
> Sling repository level implementation - above the OAK-JCR level)
> with
> Michael M and D. While this should be possible, it would
> potentially come
> with some surprises for some edge cases.
>
>
> Good! I think wrapping at the Sling level repository would still
> carry the
> limitation wrt to JCR API (Version, Observation, etc.).
> Wrapping above the JCR API may allow to remove those limitations.
>
> I am tracking one version of this idea in
> https://wiki.corp.adobe.com/display/marketingcloud/Implementation+at+JCR+le
> vel
> This version would store the shared and private content in the same
> repository.
> The JCR API would be wrapped completely and map external paths to
> internal
> paths (in and out) according to a configured mapping.
> I have added some issues that may arise with this in the wiki.
>
> I have started a version in
> https://git.corp.adobe.com/Tartan/tartan/tree/mapper/bundles/repository/imp
> l/src/main/java/com/adobe/mac/repository/impl
> And that¹s quite a lot of delegation...
>
> Regards,
>
> Timothee
>
>
> Carsten
> --
> Carsten Ziegeler | Adobe Research Switzerland | www.adobe.com
> carsten.ziegeler@adobe.com <ma...@adobe.com>
> +49 151 163 063 24 (cell)
>
>
>
>
>
>
>
> On 10.09.14 15:37, "Timothee Maret" <tmaret@adobe.com
> <ma...@adobe.com>> wrote:
>
> Hi,
>
> As a follow up from the Cloud Workshop, I have tried to
> evaluate the
> amount of work required in order support private content [0]
> path
> versioning based on Sling search path configuration.
> The result is summarized in [1].
>
> Looking at it, we may want reconsider this option as it
> would bring a
> consequent amount piece of work for a result that has some
> sensible
> drawbacks:
> * Some JCR APIs are not usable anymore in private content
> (Query, ACL,
> Observation, etc.)
> * Developers need to know about the private/shared content
> split and
> select APIs accordingly
>
> Considering the amount of work, it may make sense to try
> solving it at a
> lower level which would have the advantages of being a
> reusable solution,
> solved once for all.
> As discussed with Ian on IM, as a next step we propose to
> try wrapping
> the
> JCR Repository. The solution would be reusable and would not
> enforce API
> limitations.
>
> Regards,
>
> Timothee
>
> [0] /apps, /libs, /bin, etc. as listed in
> https://wiki.corp.adobe.com/display/marketingcloud/Marketing+Cloud+Deploy
> m
> e
> nt+Options
> [1]
> https://wiki.corp.adobe.com/pages/viewpage.action?pageId=950154974
>
>
>
>
Re: Experiment versioning path based on Sling search path
Posted by Michael Dürig <md...@adobe.com>.
Wrong list, please ignore. Sorry for the noise.
Michael
On 12.9.14 9:01 , Michael Dürig wrote:
>
> += DL-dev, as I think this topic is important enough to have a broader
> audience.
>
> Some random food for thoughts re. S2:
>
> - What about ACLs on this v1 node? These will still apply but be
> invisible through the wrapper.
>
> - What about Oak's exception messages containing paths?
>
> - Did you think of versioning and the version store? That one will
> probably contain the wrong paths unless we also apply remapping there.
>
> - JCR has the PATH property type. Do we need to map those values? All?
> Some? Which?
>
> - Tooling and management will still be using the unmapped paths.
>
> - Query is not just about mapping the queries. Its also about undoing
> the mapping in the query results. Furthermore you also need extend the
> mapping all the way through the QOM, which is exposed through the API.
>
> Michael
>
> On 12.9.14 11:13 , Alexander Saar wrote:
>> Hi Tim,
>>
>> Just had a look at your wiki pages (especially [1]). To me it sounds
>> like S2 is currently our best shot. Since you started already with a POC
>> would it make sense that you try to finish a first quick version that
>> can be used for verification? What do you think would it take in terms
>> of effort to get to a first working PoC?
>>
>> Would also love to hear if anyone has objections against this approach
>> or sees potential problems already.
>>
>> Thanks
>> Alex
>>
>> [1]
>> https://wiki.corp.adobe.com/display/marketingcloud/Implementation+at+JCR+level
>>
>>
>> From: Timothee Maret <tmaret@adobe.com <ma...@adobe.com>>
>> Date: Donnerstag, 11. September 2014 17:20
>> To: Carsten Ziegeler <cziegele@adobe.com <ma...@adobe.com>>,
>> Bertrand Delacretaz <bdelacre@adobe.com <ma...@adobe.com>>,
>> Ian Boston <boston@adobe.com <ma...@adobe.com>>, Felix
>> Meschberger <fmeschbe@adobe.com <ma...@adobe.com>>, Marc Pfaff
>> <pfaffm@adobe.com <ma...@adobe.com>>, David Bosschaert
>> <bosschae@adobe.com <ma...@adobe.com>>
>> Cc: Philipp Koch <pkoch@adobe.com <ma...@adobe.com>>, Michael
>> Marth <mmarth@adobe.com <ma...@adobe.com>>, Alexander Saar
>> <asaar@adobe.com <ma...@adobe.com>>
>> Subject: Re: Experiment versioning path based on Sling search path
>>
>> Hi Carsten,
>>
>> On 9/10/14, 14:47, "Carsten Ziegeler" <cziegele@adobe.com
>> <ma...@adobe.com>> wrote:
>>
>> Hi Tim,
>>
>> I came to a simular conclusion after finding literally thousands
>> of hard
>> coded paths in the AEM code base.
>> Some of them might be handled by hooking into some of the
>> existing
>> services (like taglib inclusion, link rewriting), but still it's
>> a lot.
>> And customers probably have similar code as they copy our "best
>> practices". Apart from taking a lot of time to get all of this
>> right, I
>> see the problem that we miss things. And both together seem
>> barely
>> manageable for us.
>>
>> I've discussed a different approach (wrapping the whole JCR api
>> on the
>> Sling repository level implementation - above the OAK-JCR level)
>> with
>> Michael M and D. While this should be possible, it would
>> potentially come
>> with some surprises for some edge cases.
>>
>>
>> Good! I think wrapping at the Sling level repository would still
>> carry the
>> limitation wrt to JCR API (Version, Observation, etc.).
>> Wrapping above the JCR API may allow to remove those limitations.
>>
>> I am tracking one version of this idea in
>>
>> https://wiki.corp.adobe.com/display/marketingcloud/Implementation+at+JCR+le
>>
>> vel
>> This version would store the shared and private content in the same
>> repository.
>> The JCR API would be wrapped completely and map external paths to
>> internal
>> paths (in and out) according to a configured mapping.
>> I have added some issues that may arise with this in the wiki.
>>
>> I have started a version in
>>
>> https://git.corp.adobe.com/Tartan/tartan/tree/mapper/bundles/repository/imp
>>
>> l/src/main/java/com/adobe/mac/repository/impl
>> And that¹s quite a lot of delegation...
>>
>> Regards,
>>
>> Timothee
>>
>>
>> Carsten
>> --
>> Carsten Ziegeler | Adobe Research Switzerland | www.adobe.com
>> carsten.ziegeler@adobe.com <ma...@adobe.com>
>> +49 151 163 063 24 (cell)
>>
>>
>>
>>
>>
>>
>>
>> On 10.09.14 15:37, "Timothee Maret" <tmaret@adobe.com
>> <ma...@adobe.com>> wrote:
>>
>> Hi,
>>
>> As a follow up from the Cloud Workshop, I have tried to
>> evaluate the
>> amount of work required in order support private content [0]
>> path
>> versioning based on Sling search path configuration.
>> The result is summarized in [1].
>>
>> Looking at it, we may want reconsider this option as it
>> would bring a
>> consequent amount piece of work for a result that has some
>> sensible
>> drawbacks:
>> * Some JCR APIs are not usable anymore in private content
>> (Query, ACL,
>> Observation, etc.)
>> * Developers need to know about the private/shared content
>> split and
>> select APIs accordingly
>>
>> Considering the amount of work, it may make sense to try
>> solving it at a
>> lower level which would have the advantages of being a
>> reusable solution,
>> solved once for all.
>> As discussed with Ian on IM, as a next step we propose to
>> try wrapping
>> the
>> JCR Repository. The solution would be reusable and would not
>> enforce API
>> limitations.
>>
>> Regards,
>>
>> Timothee
>>
>> [0] /apps, /libs, /bin, etc. as listed in
>>
>> https://wiki.corp.adobe.com/display/marketingcloud/Marketing+Cloud+Deploy
>> m
>> e
>> nt+Options
>> [1]
>>
>> https://wiki.corp.adobe.com/pages/viewpage.action?pageId=950154974
>>
>>
>>
>>
>