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
