jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: oak api : initial draft
Date Thu, 29 Mar 2012 15:38:27 GMT
Hi

Thanks for this.

Some notes from my part:

(0) I assume the API is just the 4 classes in the oak.api package, right ?

(1) I understand the RepositoryService is the single access point into Oak "from the outside"
which is fine. Still I think the name "RepositoryService" sounds wrong to me. Rather it looks
like a ConnectionFactory: You feed some credentials and you get back a connection.

(2) The credentials to the RepositoryService (or ConnectionFactory) are a plain Object. I
understand that this is just slightly lighter than the JCR Credentials. But since all credentials
will probably always come with at least a User name we might want to create a proper Object
to supply the user name and stipulate more credential detail. 

(3) The connection factory method in the RepositoryService (or ConnectionFactory) is not usable
for multi-factor authentication where a challenge may be sent to the client to be replied
to. Is this by intent ? Do we want to support such multi-step authentication on this level
or not ? I understand the JCR spec does not support it either and pushing such a challenge
back from Oak through the JCR API is a challenge in itself.

(4) The Connection provides access to o.a.j.mk.model objects (NodeState, NodeBuilder). This
is not wrong per-se. In an OSGi environment where core and mk may be deployed as separate
bundles, this means the mk.model package must be exported but this should not be exposing
mk implementation detail.

(5) The AuthInfo returned form the Connection implies getting some information about the user.
How about also using this AuthInfo actually as the credentials used to create the connection
(along the lines of #3 above) ?

(6) CommitFailedException is a checked exception. Do we really want this ? In addition, we
said, there should be a root exception, right ?


Regards
Felix

Am 28.03.2012 um 10:11 schrieb Angela Schreiber:

> 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