jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: oak api : initial draft
Date Wed, 28 Mar 2012 19:13:21 GMT


Some more things that crossed my mind:

- Is it possible to open multiple Connection instances with one 
SessionInfo? What would be the purpose of this? Can I commit a NodeState 
created with a NodeBuilder from one Connection into another Connection?

- Wouldn't it be simpler and sufficient to have a 1:1 relationship 
between SessionInfo and Connection? Again: can I commit a NodeState 
created with a NodeBuilder from one Connection into another Connection 
(from another SessionInfo in this case)?

- Do we want to make any guarantees wrt. thread safety on Connection?

- Having NodeState and NodeBuilder in the oak-core API currently 
introduces a dependency on oak-mk for clients of that API. We should 
probably move the interfaces which are used across the stack to some 
common location.

- ... probably more to come ;-)


On 28.3.12 15:11, Angela Schreiber wrote:
> hi all
> jukka and myself just were sitting together to define an very
> first draft of the oak-api just to have something to start with
> and to have a basis for further discussions.
> i will commit it as soon as i run the build without error.
> it will consist of an initial Service that provides
> - login providing a sessioninfo
> - ability to retrieve a Connection for that sessioninfo
> the Connection (still to be defined it this represent a workspace
> or the whole repository) would then give access to node states (based
> on permissions for the session associated with it), be in charge
> of validating changes to be committed and executing queries.
> will doing so we still had a lot of open questions some of which
> are marked as todos in the interfaces.
> feedback is welcome
> regards
> angela
> On 3/28/12 3:50 PM, Michael Dürig wrote:
>> On 28.3.12 14:27, Thomas Mueller wrote:
>>> Hi,
>>>> Could you come up with an implementation which does not directly depend
>>>> on the Microkernel but rather uses a (to be defined) API on oak-core?
>>> Sure, let's define such an API.
>> I'll try to come up with some ideas later today. Need to get a clearer
>> picture for myself first.
>>>> I'm in the process of removing all dependencies from oak-jcr to oak-mk
>>>> (OAK-20) so this will ultimately break.
>>> Sure. What I used is a temporary workaround, this is not meant to
>>> stay as
>>> it is.
>> Ok great.
>> Michael
>>> Regards,
>>> Thomas

View raw message