Hi,

Some initial comments to the API draft below:

SessionInfo.dispose(): do we need this? To me SessionInfo looks like a 
state less data object (i.e. a value) carrying information related to a 
user's session. I think we should try to not associate any resources to 
be disposed with this. These should go into Connection. That is, I'd 
remove the dispose() method initially and add them back later on when we 
have a compelling reason to do so.

Whether a Connection is repository bound or bound to a single workspace 
depends on whether we want to expose the concept of a workspace through 
the oak API or whether the oak API should rather expose a tree and we 
decorate workspaces on top in oak-jcr. Maybe thinking of the other 
bindings for the oak API gives us a better clue.

CommitFailedException (mechanism to inform the oak-jcr level about the 
specific type of exception):
- nested jcr exception: this would create a dependency of oak-core on 
jcr which we might want to avoid.
- extends RepositoryException: same as above but much worse: checked 
exceptions don't compose. That is, we'll get into lot of problems being 
forced to handle these exceptions in implementations of interfaces which 
do not allow exceptions to be thrown (Iterator.next, Comperator.compare, 
...).
- Status code: I think this is the way to go. I'd include the status 
code as an enum in the exception.

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