jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: oak api : initial draft
Date Wed, 28 Mar 2012 19:51:57 GMT

On Wed, Mar 28, 2012 at 9:13 PM, Michael Dürig <mduerig@apache.org> wrote:
> - 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)?

I think it would make sense to merge SessionInfo and Connection to a
singe interface. The main reason we didn't do that yet is the handling
of credentials and session attributes (i.e. as a way for custom
authentication components to pass information back and forth across
the API) that felt out of place in Connection. I'd rather get rid of
session attributes entirely at this level (and use the JAAS model for
any across-the-stack communcation), but I think we need to keep it for
now for compatibility with existing authentication components designed
for Jackrabbit 2.x.

Anyway, having thought about this a bit more, I'd support merging
SessionInfo and Connection to a single Connection (or some other
similarly named) interface.

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

I don't see a strong use case where we'd need thread-safety at this
level. Unless we come up with one, I suggest we don't make such
guarantees on Connection level.

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

Right. This would be a non-issue if we hadn't split oak-core apart...

Anyway, I'd rather keep the oak-mk reference as is for now until we
encounter a case of why we'd truly need a different tree model on the
oak-core level. For example the CoreValue class that Thomas now has
for the query code might well be something that we need to consider
also from an API perspective.


Jukka Zitting

View raw message