Re: Need help getting Slide to use LDAP.

[Alan Wood]

On Tue, 25 May 2004 09:38:25 -0700, James Mason <[EMAIL PROTECTED]> wrote:
It might be posible to define a standard mechanism, maybe by writing
some Abstract Store class for a partial or "transparent" store, where
a
store that does not handle an operation it delegates to the parent
store. For example, you mount a standard store on /, Tx or JDBC, and

then you mount the LDAP store on /users and /roles. If the LDAP store

doesn't handle a given operation, like creating arbitrary properties,
it
delegates to the root store.
I was thinking of something along those lines. Having a dual-mode Store
that put some things in LDAP and some things in a filesystem/database. I
hadn't thought of passing the additional properties up to a
higher-scoped Store. That makes sense. I'm not sure how that would play
out with the current API, and I can see the potential for concurrency
issues (deleting a user in LDAP but still having properties in the
parent store). I like the idea, though.

Although this would be handy I am not sure it is feasable after looking at 
the TX store and XMLDescriptors et all... The stores store nodes for a 
given URI, a node itself consists of other nodes (properties, value 
permissions etc..) what seems to be suggested here is differentiating 
storage for these different node components (leaves of the tree). I 
believe this may destroy the node abstraction fundamental in slide. I also 
find it difficult to imagine how transactions would be handled accross the 
nodes given that some have an LDAP route and others have a file stream 
route. Now Im no expert here it's my first look at the store example code, 
but my feeling would be that LDAP would have to house all of the nodes 
under the user tree (and roles would also make sense here i believe). This 
would again raise the issue of LDAP schema issues with existing schemas in 
the LDAP instalation for users.groups etc.. It would also mean a lot of 
work me thinks.

I think the real issue here is that slide has not been created with an 
abstract or seperable user/role model, but instead treats these as nodes 
of the existing model, stored alongside everything else (I dont mean this 
as a critisism, just an observation).

It would be nice if someone else here with direct experience of the store 
developement could add some input to clarify. Any takers?

Al
--

[EMAIL PROTECTED]
<<<<<<<<<<<<<<<<<<<<<<<<<<<
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]