jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: oak api : initial draft
Date Wed, 28 Mar 2012 15:09:00 GMT
hi michi

just as an additional side note:
the conversation between jukka and myself also included some
first ideas on how a given repository is being created,
who is being in charge of the initial setup and creating the
mk and the service instance and how once the repository
exists a new instance of the JCR repository is being retrieved
from the factory.

jukka promised to work on this such that we will soon be able
to get a clearer picture here as this basically has an impact
on everything related to oak-jcr and oak-core.

kind regards
angela

On 3/28/12 4:58 PM, Michael Dürig wrote:
>
> Great! I was just about to start working on this since this is also a
> prerequisite for getting OAK-20 resolved. I'll have a look at the draft
> and let you know.
>
> Michael
>
> 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
>>>>

Mime
View raw message