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.
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?
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.
Carlos
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
