Paul Sandoz <[EMAIL PROTECTED]> writes:
> [Resending; news server problems]
>
> Dan Mosedale <[EMAIL PROTECTED]> writes:
> >Well, there maybe issues in the amount of information that a standard
> >LDAP URI can hold, as per the other message I just posted. But doing
> >the new URI schemes suggested in the refactoring proposal might work.
> >Although maybe just changing the syntax of the existing abook: scheme
> >and putting the ldap || mdb || ... after the colon would help keep us
> >from polluting the URI scheme namespace too much. After talking this
> >over with hixie and dbaron, I filed bug 69513; if adding more schemes
> >is the right thing to do, that will be relevant to how the new
> >schemes get named.
> >
>
> 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.
> <slightly-off-topic>
> I presume at some point that this .js file is going
> to change to RDF?, a general prefs editor using an RDF
> schema could be interesting esp. for enterprise where
> preferences could be stored in an LDAP server.
> </slightly-off-topic>
An interesting idea. I don't know of any such plans, but that's not
to say that there aren't any. You might try asking in the .prefs
newsgroup.
> 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?
> Also perhaps the scheme 'abmdbdirectory' could be better
> stored as 'moz-pab' in the preferences?
This seems reasonable to me.
> It is possible to use the number defining the type
> of address book i.e. type=0, but i think that it is
> really ugly. Or even uglier have a:
>
> if (dirType == 0)
> else if
> .
> .
>
>
> We can get by with the former 'ugly' as an interim solution.
Yeah; agreed that this seems unnecessarily ugly.
Dan
--
