Hi, On Wed, Mar 28, 2012 at 9:13 PM, Michael Dürig <[email protected]> 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. BR, Jukka Zitting
