+= 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 <[email protected] <mailto:[email protected]>>
Date: Donnerstag, 11. September 2014 17:20
To: Carsten Ziegeler <[email protected] <mailto:[email protected]>>,
Bertrand Delacretaz <[email protected] <mailto:[email protected]>>,
Ian Boston <[email protected] <mailto:[email protected]>>, Felix
Meschberger <[email protected] <mailto:[email protected]>>, Marc Pfaff
<[email protected] <mailto:[email protected]>>, David Bosschaert
<[email protected] <mailto:[email protected]>>
Cc: Philipp Koch <[email protected] <mailto:[email protected]>>, Michael
Marth <[email protected] <mailto:[email protected]>>, Alexander Saar
<[email protected] <mailto:[email protected]>>
Subject: Re: Experiment versioning path based on Sling search path
Hi Carsten,
On 9/10/14, 14:47, "Carsten Ziegeler" <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
+49 151 163 063 24 (cell)
On 10.09.14 15:37, "Timothee Maret" <[email protected]
<mailto:[email protected]>> 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
