jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mic...@gmail.com>
Subject Re: oak api : initial draft
Date Wed, 28 Mar 2012 20:32:26 GMT
On Mar 28, 2012 8:52 PM, "Jukka Zitting" <jukka.zitting@gmail.com> wrote:
>
> Hi,
>
> 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.

Connection seems like a good name to me. Re. Session attributes: we could
encapsulate these and other information regarding authentication in a
AuthInfo class which can be retrieved from the connection.

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

+1. Let's state this explicitly in the javadoc.

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

Ok ack. Afaics we might need a different tree model anyway at some point.
1. Since we probably want to return CoreValue instances instead if Scalar.
And 2. Since the tree builder needs to expose additional information for
transient nodes (e.g. isNew, isModified).

Michael

> BR,
>
> Jukka Zitting

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message