This list of xsd namespaces, instead of using List<String>, wouldn't be better to user TreeSet<String>? Once you need to look up for namespaces on the list frequently, unless if there are another reason to use List that I'm not aware about : )
Regards, Adriano Crestani On 7/24/07, Ole Ersoy <[EMAIL PROTECTED]> wrote:
Luciano Resende wrote: > Are we trying to make it much more complex ? :-) I'm a big believer in as simple as possible, but no simpler. > 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 ? You are right. Having the whole configuration file in the DIT does not make much sense. Initially I was thinking that the config file would contain a list of all the xsd namespaces representing the schemas that are written to the server. But now I'm thinking that this list should be contained on the server, but will remain independent of the config file. The DAS then goes through the following sequence before writing a graph: - Lookup the supported schemas (List of xsd namespaces) in the DIT (Just creates a List<String> of xsd namespaces) - See whether the list contains the xsd namespace for the graph that is about to be written - If it does, write the graph - If it does not, write the schema - Add the xsd namespace string to the supported schema list - Update this list on the server Sound OK? SNIP > > 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... > Sure - I'm just implementing the things we are going over right now, and then I'm going to write a users guide, followed by updates to the design guide. The remaining (For a working LDAP DAS) task list looks approximately like this: - Finish the DAS Interface / object (Main CRUD Interface (LdapDAS.write(EDataGraph), .... ) - Test the DAS Interface / object - Finish and test JNDI Connection pooling configuration (Low priority) - Update the EDataGraphCreator to ignore "Transient" properties (Right now it will write all the properties) - Add support for multiplicity many EAttributes (Right now it just assumes that they are singular) - Complete users guide - Complete design guide - Formal Apache review Thoughts? SNIP --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
