On Sat, Jan 24, 2015 at 4:55 AM, Stefan Seelmann <m...@stefan-seelmann.de> wrote:
> On 01/23/2015 09:07 PM, Emmanuel Lécharny wrote: > > Thinking about it, as soon as the schema elements stored in the > > subschemaSubentries are supposed to be standardized by RFC 4512, there > > is no reason the existing code should not work with any server, except > > that we should remove the > > > > if ( isApacheDs( rootDse ) ) > > > > check... > > This is what I just wanted to write. > > That should work, but in reality it doesn't because some LDAP servers > return incomplete or invalid information. > > In Studio for the "LDAP Browser" we load the schema from > subschemaSubentry of the rootDSE when opening a connection (different > subschemaSubentries are not supported currently) and handle lot of > special cases: > > * the "quirks" mode for the schema parsers is enabled which e.g. accepts > non-numeric OIDs and doesn't check references (SUP, SYNTAX) between > schema elements > > * For missing schema elements (e.g. if the server doesn't provide any > ldapSyntaxes) we create "dummy" elements to make the schema model > consistent. > > This is implemented in class > org.apache.directory.studio.ldapbrowser.core.model.schema.Schema [1]. > > The aim of this implementation is to have a usable schema to assist the > user when creating and editing entries or to be able to browse the > schema via the schema browser. > > > For the "Schema Editor" there is a different implmentation > org.apache.directory.studio.schemaeditor.model.io.GenericSchemaConnector > [2]. The aim of this implementation is to collect all error in the > schema and list them in the error view. But still we create dummy > syntaxes and matching rules if missing. > > > You see there are different use cases (strict validation vs. relaxed > validation + present problems vs. try of fix invalid schemas to make > them usable). I'm not sure if it is possible to refactor the code to > have a single implementation that supports all use cases. > > I think we should move all these various loaders into API then the subsequent improvements proposed in the first mail can be applied on these. wdyat? > Kind Regards, > Stefan > > > [1] > > https://svn.apache.org/repos/asf/directory/studio/branches/studio-tycho/plugins/ldapbrowser.core/src/main/java/org/apache/directory/studio/ldapbrowser/core/model/schema/Schema.java > > [2] > > https://svn.apache.org/repos/asf/directory/studio/branches/studio-tycho/plugins/schemaeditor/src/main/java/org/apache/directory/studio/schemaeditor/model/io/GenericSchemaConnector.java > > -- Kiran Ayyagari http://keydap.com
