Sling IDE API - Refactoring

[Konrad Windszus <ko...@netcentric.biz>]

In the context of https://issues.apache.org/jira/browse/SLING-4043 I had a closer look at the Sling IDE Tooling API again and made a new proposal on it in https://cwiki.apache.org/confluence/x/eAsjB.
That should solve several of the issues we had with the API in the past.
It would be good to hear some feedback on that, some parts are only roughly outlined up till now, especially the SerializationManager part seems to be a tricky one.
I would like to hear some feedback on the proposal before I go ahead and implement that in a dedicated feature branch on Github.
Thanks,
Konrad

Re: Sling IDE API - Refactoring

[Konrad Windszus <ko...@gmx.de>]

> On 14. Apr 2017, at 13:27, Robert Munteanu <ro...@apache.org> wrote:
> 
> Hi Konrad,
> 
> On Wed, 2017-04-12 at 15:14 +0200, Konrad Windszus wrote:
>> In the context of https://issues.apache.org/jira/browse/SLING-4043 I
>> had a closer look at the Sling IDE Tooling API again and made a new
>> proposal on it in https://cwiki.apache.org/confluence/x/eAsjB.
>> That should solve several of the issues we had with the API in the
>> past.
>> It would be good to hear some feedback on that, some parts are only
>> roughly outlined up till now, especially the SerializationManager
>> part seems to be a tricky one.
>> I would like to hear some feedback on the proposal before I go ahead
>> and implement that in a dedicated feature branch on Github.
> 
> Thanks for taking this up, the proposal looks good overall.
> 
> Some specific comments:
> 
> 1. The ResourceProxy allows access to children but not to parents. Why
> not parents as well? The current version sort of evolved from a thin
> layer of properties to allow children access, but I'm not sure why we
> don't allow that in the future.
That way it is harder to insert children, because each child needs to maintain a link to the parent. I would suggest that we only add getParent() once there is a real good use case for it. Right now I fail to see one.

> 
> 2. For the ResourceProxy it might be worth introducing a PropertyType
> concept. Right now IIRC we don't distinguish between the Reference and
> WeakReference because they are both backed by an UUID.
Yes, might make sense. So it would be like Map<String, PropertyType> getProperties()? What would PropertyType expose? Most some metadata (like JCR type for JCR-backed resource proxies), the actual (typed) value and a boolean flag for multivalue. Anything else?

> 
> 3. Where would the ResourceManager fit in for the IDE tooling?
> Currently we have a command concept that is used to perform remote
> changes, which allows us to do batching/sorting/compacting.
The batching is now supported through the ResourceManager.commit() which should be fine for both the FS based manager as well as the DavEx remote access. Sorting is IMHO not that useful only compaction may be applicable here, but the DavEx manager would do the compaction internally and for the FS based manager it is not that useful IMHO. What I have in mind is one (DavEx) resource manager to publish the changes, which either works incrementally (i.e. after a save to a file it would first check the current remote status and would then calculate the necessary operations on the resource manager to achieve the to-be status) or a full publish which would just overwrite the relevant resources completely. The FS based resource manager would not support incremental writes but would always serialize the full resource.

> 
> Robert
> 
> 

Re: Sling IDE API - Refactoring

[Robert Munteanu <ro...@apache.org>]

Hi Konrad,

On Wed, 2017-04-12 at 15:14 +0200, Konrad Windszus wrote:
> In the context of https://issues.apache.org/jira/browse/SLING-4043 I
> had a closer look at the Sling IDE Tooling API again and made a new
> proposal on it in https://cwiki.apache.org/confluence/x/eAsjB.
> That should solve several of the issues we had with the API in the
> past.
> It would be good to hear some feedback on that, some parts are only
> roughly outlined up till now, especially the SerializationManager
> part seems to be a tricky one.
> I would like to hear some feedback on the proposal before I go ahead
> and implement that in a dedicated feature branch on Github.

Thanks for taking this up, the proposal looks good overall.

Some specific comments:

1. The ResourceProxy allows access to children but not to parents. Why
not parents as well? The current version sort of evolved from a thin
layer of properties to allow children access, but I'm not sure why we
don't allow that in the future.

2. For the ResourceProxy it might be worth introducing a PropertyType
concept. Right now IIRC we don't distinguish between the Reference and
WeakReference because they are both backed by an UUID.

3. Where would the ResourceManager fit in for the IDE tooling?
Currently we have a command concept that is used to perform remote
changes, which allows us to do batching/sorting/compacting.

Robert