>> I don't think it is necessary to store all preferences
>> in the URI, the minimum to identify the type, location
>> and maybe user would suffice for LDAP. An interim
>> solution could be to maintain both in the preferences
>> reusing one preference attribute as the uri, a good
>> candidate would be 'filename'. Hmm... maybe not because
>> this is used to identify the off-line db file for ldap,
>> but there is no concept of offline for ldap yet +
>> the offline address book could be identified as a uri
>> as well... ramble ramble....
>
>Well, Leif and I did a bunch of design work on the nsLDAPService code
>last Thursday, and we came to the conclusion that it would make the
>most sense to stuff as much info as we can into LDAP URIs and store
>that in the prefs (just converting old prefs to the new prefs format),
>and just use an extra pref or two to augment that as necessary. Leif
>will be posting info from that meeting here soon.
>
Yes, i agree and its not necessary to coerce the URI
format to store everything.
>> Also i think that there is no need to impose the address
>> book name space on an organisational ldap preferences.
>>
>> We would like to instantiate nsIAbDirectory RDF resource
>> components through corresponding factory components
>> which have contract ids like:
>>
>> @mozilla.org/addressbook/directory-factory;1?type=ldap
>> @mozilla.org/addressbook/directory-factory;1?type=abmdbdirectory
>> @mozilla.org/addressbook/directory-factory;1?type=outlook
>>
>> An LDAP address book directory factory can return an
>> RDF resource component with a URI defined by the scheme
>> 'abldapdirectory'
>
>So shouldn't the first contract id use "type=ldapabldapdirectory"? Or
>I am misunderstanding how you mean to construct these contract ids?
>
The plan would be somthing like:
o obtain the uri in the preferences,
o call somthing like GetDirectoryFactory (uri) on
an address book factory interface
- this would obtain the scheme prefix
@mozilla.org/addressbook/directory-factory;1?type=
to the scheme and instantiate the relevant
component to return which implements a directory
factory interface
- We would then call CreateDirectory (pref properties...)
which returns a directory interface of an RDF
directory resource component which represents
the address book implementation.
I was trying to distinguish between URIs used in the
preferences and URIs used for RDF resources. The LDAP
factory will return a RDF directory resource with the
URI scheme 'abldapdirectory'.
The LDAP preferences could be used by other clients which
are not interested in address books directories like the
LDAP auto-completion code. So I thought it was better to
keep the generic scheme and let the factories return more
specific schemes in line with the more specific functionality.
Paul.
| ? + ? = To question
----------------\
Paul Sandoz
x19219
+353-1-8199219