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 Thu, 29 Mar 2012 15:55:49 GMT
Hi,

On Thu, Mar 29, 2012 at 5:38 PM, Felix Meschberger <fmeschbe@adobe.com> 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

Mime
View raw message