Other SPI design questions, was: SPI caching, was: [jira] Resolved: (JCR-1361) Lock testassumes that changes in one session are immediately visible in differentsession

[Julian Reschke <ju...@gmx.de>]

David Rauschenbach wrote:
>  
> Some other SPI deficiencies off the top of my head, while we're on the
> subject:
> 
>   1. Default workspace name. They should not be specified in JCR2SPI.
> When you log into Exchange or an IMAP server, or a SQL Server, you get a
> default namespace (or database) based on what the server thinks is the
> right default name for you. The name should not be known at the client
> (that's why it's a default!). Once you're logged in, you can ask for
> other namespace names, which also fits in nicely with JCR
> (Workspace.getAccessibleWorkspaceNames). But specifying a default
> namespace name in JCR2SPI is wrong, because a null should be passed when
> the server should choose.

We're talking about RepositoryConfig, right?

My implementation just returns "", which my RepositoryService takes to 
mean that the default workspace should be returned. But it's not the 
default workspace name.

Anyway, I agree this seems to be useless. Let's get rid of this, and let 
it work just as in JCR.

>   2. Repository descriptors over SPI. This is a deficiency. I have a web
> service that remotes SPI, and I can't ask the target web service for the
> repository descriptors. It doesn't help that JCR2SPI asks for the
> descriptors before a login. That makes it almost mandatory to mock up
> fake values in the SPI, before a dynamic proxy can initialize itself, if
> initialization is dependent on logging in, as is the case in 2 out of
> the 5 SPIs I have in front of me, or in cases where the target web
> service is deployed under the umbrella of container-managed security.

Repository descriptors are a design problem in JCR itself, as they 
always apply to a whole repository.

Thus, a server that aggregates multiple different kinds of store as a 
"virtual" repository always will have to lie.

>   3. Out-of-band data. Since JCR doesn't address configuration, or a
> RepositoryFactory pattern (even though Jackrabbit provides one), it is

...proposed for JSR-283...

> up to each implementation to get configuration done. SPI could use a
> place to pass this data. SimpleCredential attributes are not enough.

We currently support RepositoryConfig configuration using JNDI. There's 
also the plan to replicate whatever we get in JSR-283 into SPI, but I 
don't think we've done that yet.

> IIOP for CORBA is a good example, where you can stuff profiles with your
> extra data, like timezone of the client, alternate server names,
> whatever. For SPI, the out-of-band data could be a place where the
> implementation-specific BatchReadConfig for a specific getItemInfos
> operation could be placed. I'm not sure this is a good idea for SPI, but
> I'm thinking about it.
> 
> David

BR, Julian