Are we trying to make it much more complex ? Are users going to get confused to think they have a local copy of the XML config file, but the LDAP DAS is really using the one stored on the server ? I'd suggest we start simple, and have the user turn the flag on/off, we could also make the flag more flexible, with some other attributes, like weather or not to check on every start, force schema generation on the server, etc ? I think this would avoid confusion.
BTW, it would be great if you could add some overview design doc on the Wiki, also some sample code, or pointers to sample code, etc... On 7/22/07, Ole Ersoy <[EMAIL PROTECTED]> wrote:
Hi Luciano, Luciano Resende wrote: > Very good to hear these news Ole. > > Regarding your question, does "create the LDAP type system" means > creating the LDAP schema on the LDAP server ? Yes > Do you also have the > scenario of updating the schema ? Yes as long as the Schema update is versioned using the xsd namespace, as in http://maven.apache.org/pom/3.0.0 vs. http://maven.apache.org/pom/4.0.0 > What about pre-populating like in > sample applications ? The tests populate, so for stress testing and so on it's just a matter of building on these. > Well, if you have these scenarios, maybe it > would be better to use an utility to allow applications to do that, we > have a similar thing in RDB DAS (dbConfig). When I woke up this morning it occurred to me that I can just store the DAS's config in the LDAP Directory Information Tree (DIT .... LDAP Storage Structure). That's a typical LDAP usage scenario anyways. What we could do is on first startup, store the configuration in the DIT, then on subsequent starts the minimal connection information is read from the config file, and the rest comes from the DIT. When the user wants an updated configuration file, she just loads the configuration in the DIT and serializes it to XML. Sound OK? > > As for the other option, that you mentioned, are you always going to > have access to the configFile? > In the case of RDB DAS, we allow for > configuring only by passing a Stream, and in this case I guess you > solution would fail. I think this scenario would be covered by storing the configuration in the DIT. Thoughts? Thanks, - Ole SNIP --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
