Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of anchela@adobe.com designates
 64.18.1.189 as permitted sender)
Message-ID: <4F86C6F7.20601@adobe.com>
Date: Thu, 12 Apr 2012 14:13:43 +0200
From: Angela Schreiber <anchela@adobe.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: <oak-dev@jackrabbit.apache.org>
Subject: Re: Different types of 'item modification' on oak-jcr (and oak-api)
References: <4F85A60E.3020709@adobe.com> <4F85B19C.5030601@apache.org>
 <4F8688B1.5050206@adobe.com> <4F869CC0.8030907@apache.org>
In-Reply-To: <4F869CC0.8030907@apache.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

hi michael

>> that looks really wrong to me. the way i think of the oak-api
>> is that i obtain the connection from oak-api upon Repository.login
>> and it would be used for the communication for the lifespan of the
>> JCR session obtained. retrieving another connection is definitely
>> not what i am looking for as it would require separate
>> authentication. that doesn't make sense to me.
>
> See my reply to Jukka and my related commit of rev. 1325159.

well, i still don't see how/where you plan to implement
the notion of transient modification.

in other words to make it clear (in case it isn't):
how do i change protected items in oak-jcr such that the items
are marked modified and the session has pending transient changes?
and such that i don't have to use the JCR API methods, which in
this case from my understanding are 'invalid'?

so, how do we make sure that
Session#hasPendingChanges
Item#isNew
Item#isModified
never return true in case the workspace operation fails on the oak
api for constraint or access violation and on the other hand
assert that all kind of transient modifications really trigger
the flags to be set?

i couldn't follow you here since those methods are not implemented.

>>> Regarding the "special modifications" we still need to come up with a
>>> way to handle those. They should IMO also be done through the
>>> Connection, NodeEditor, etc. interfaces which might need to be tweaked
>>> accordingly.
>>
>> as stated before i have the impression that this would need to
>> be reflected on the API.
>
> Yes, that's what I said. So let's come up with a way to do that.

let's first define how to distinguish transient modifications.
i think that is the special case here from a oak-api perspective.

> Workspace operation should be doable now with my changes in rev.
> 1325159. I will try to implement copy and move to validate this.

i added a check for srcWorkspace not being the current workspace.

> TransientNodeState turned out to be a bad name for several reasons: 1.
> it implies being a NodeState which it isn't, and 2. it implies a one to
> one correspondences with transient modifications of JCR items which
> seems a too restrictive assumption.

see above.

>
> I think the next steps should be:
>
> 1. Validate my claim from above re. workspace operations

what was your claim? can't follow you here.

> 2. Come up with a way to do "special modifications" following the
> general direction sketched by NodeStateEditor et. all. This might
> require adding higher level abstractions to the oak API and/or oak-jcr
> and might also require changes/tweaks to the current state of affairs.

well, your approach of having a separate editor for workspace
operations already goes into the direction of separating
different change-sets. that was one thing i was wondering about.

IMO we we can basically use the same behavior for registering a
node type and an namespace or a privilege under /jcr:system/something... 
(the latter was actually what brought up my
questions). oak-core was in any case in charge of validating the
changes individually and detecting the distinction between
a change to the node type registry or just a workspace. so,
maybe we can use the same mechanism.

what do you think?
angela


> 3. In the process come up with better names.


> Michael
>
>>
>> kind regards
>> angela
>>> Michael
>>>
>>>>
>>>> kind regards
>>>> angela
>>>>