[snip]
Alan Wood wrote:
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.
Well, I am not expert either, but I have a working "mixed" store along those lines. As you said, a slide node is made of other pieces. But it doesn't matter where those pieces come from as long as the overall view of the object is consistent. I implemented a EJB Store based on the JDBC samples, however, the user/roles come from existing User/Role beans in my application. In fact the User bean may be an LDAPUser or and DatabaseUser, which my application already had. I have several abstractions in between, because other parts of my application needs them, but it could be done with the default stores. The transaction stuff could be tricky, I haven't tested my implementation thoroughly. So far it seems to work. But if LDAP is readonly, it doesn't matter.
I didn't use what I suggested, passing unsupported operations to the parent store. Rather, I handled it internally, as far as Slide is concerned there's only one store mounted at the root. Basically, for LDAP, you just need to implement retrieveObject and retrieveRevisionDescriptor, the rest is passed along. However, I think it's possible to generalize this and use the scope concept in Slide as suggested. The problems I see are the same James mentioned: the current API may be lacking and how to synchronize external changes to user/roles. Deleted users in LDAP may not be a problem because you always check LDAP first and can invalidate the orphan local objects. But there are other cases like deleting and readding, or even some modifications may also create inconsistencies. Maybe a timestamp check to discard local related objects will do the trick.
I see where your coming from, using the readonly store implementation (for say user and password) avoids the transaction issues. But if this were to be implemented (just user and password) it would be best to create the store so that it outsourced authentication in a standard way using JAAS, that way you could easily design any backend for authentication i.e. LDAP, SQL or even another Slide !! just joking about that last one ;)
PS there are also some diadvantegs to just user/password storage changes, promarily that from a admin point of view you now have two points of admin LDAP for user name and passwords and other permisssions and WEBDAV/Slide for ACLs which isnt exactly a global admin view.
Al
--
[EMAIL PROTECTED] <<<<<<<<<<<<<<<<<<<<<<<<<<<
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
