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
