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.29 as permitted sender)
Message-ID: <4F8688B1.5050206@adobe.com>
Date: Thu, 12 Apr 2012 09:48:01 +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>
In-Reply-To: <4F85B19C.5030601@apache.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

hi michael

> On 11.4.12 16:41, Angela Schreiber wrote:
>> hi
>>
>> thinking about how to implement the various JCR level operations
>> that are beyond regular item modification, i found that IMO
>> will face at least the following 4 types of writing that would
>> from a oak-api point of view may just look like item state
>> modifications:
>>
>> a) Regular JCR Item Modification [...]
>> b) Special JCR Item Modification  [...]
>> c) Non-Transient JCR Item Modifications  [...]
>> d) Non-Transient Special Item Modification  [...]

>> when looking at the current oak-api and the NodeStateEditor i
>> don't see how we would currently be able to distinguish these
>> different types.
>
> The current API should be able to cope with transient modifications and
> non-transient modifications. The latter can be done by obtaining a new
> connection just for those changes.

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.

> 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.

> The name reflects "transient" from JCR and should emphasis the fact that
> instances of this class are - in contrast to NodeState - not Immutable.
> However, we could rename this not MutableNodeState or something
> different if you prefer.

well... but in fact we would probably want to distinguish between
transient operations that mark the associated JCR items modified/new
until Session.save() is call, whereas all kind of workspace
operations would never have that effect.... figure out the workspace
operation fails during validation on oak-core. there should by
no means a 'modified' flag being pending on the corresponding
jcr items... we didn't that in the early stages of jackrabbit-core
(as long as we had no real access control) and it didn't work.

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