Hi, On Thu, Mar 29, 2012 at 5:38 PM, Felix Meschberger <[email protected]> wrote: > (0) I assume the API is just the 4 classes in the oak.api package, right ?
.oak.api is the place, yes. As you noticed, the API currently references also interfaces in .mk.model, but that's to be fixed. > (2) The credentials to the RepositoryService (or ConnectionFactory) are a > plain Object. I understand that this is just slightly lighter than the JCR > Credentials. But since all credentials will probably always come with at > least a User name we might want to create a proper Object to supply the > user name and stipulate more credential detail. > > (3) The connection factory method in the RepositoryService (or > ConnectionFactory) is not usable for multi-factor authentication where > a challenge may be sent to the client to be replied to. Is this by intent? > Do we want to support such multi-step authentication on this level or > not? I understand the JCR spec does not support it either and pushing > such a challenge back from Oak through the JCR API is a challenge > in itself. All that stuff should IMHO be handled through the standard JAAS mechanism. As mentioned in my earlier email, I dislike even passing explicit credentials objects or session attributes across the Oak API (that should all be handled by JAAS), but for compatibility with existing authentication components based on Jackrabbit 2.x we probably need to keep credentials and session attributes as opaque Objects in the API. > (4) The Connection provides access to o.a.j.mk.model objects > (NodeState, NodeBuilder). As discussed, this is a topic that still needs to be resolved. We're using the .mk.model interfaces for now to avoid simply duplicating them. > (6) CommitFailedException is a checked exception. Do we really want this? I do, but others disagree. To be discussed. > In addition, we said, there should be a root exception, right ? Why? This is a specific, strongly typed part of the commit() signature as drafted. I don't (yet) see a need for it to be related to any other exception in the API. Most notably I don't see much need for a generic "Oak-" or "RepositoryException" that a client can't do anything reasonable with. Let's just use RuntimeException for such cases. BR, Juka Zitting
