>> Preferences and URI definition
>> Need schemes/uris for different address data sources
>> and more saved preferences associated with each
>> source.
>>
>> abdirectory:mozilla://abook.mab
>> abdirectory:ldap://user@host:port/blah
>> abdirectory:ldap-web-top://user@host:port/blah
>> abdirectory:evolution://foo/bar
>>
>> likewise for a card. Each scheme type can define the
>> way to represent a card.
>> Therefore can register components with abdirectory
>> schemes?
>
>I think I must be missing something obvious: why is the abdirectory:
>prefix necessary?
>
Hmm... i think it needs to be unique so that different
address RDF data sources and resources can be connected
to specific data source functionality.
It is 'abdirectory:ldap:' and not 'ldap:' because ldap is being
used in a specific way to:
obtain address data and serve it up as RDF that
conforms to what it means to be address data which
is independent of data source.
perform operations like delete address book,
add card etc...
The 'abdirectory:ldap:' source impl chould chop of the
'abdirectory:' and get use this uri to get access to the
ldap server to obtain the data and map it?
(is this similar to how monikers work?)
>> Auto-Completion
>> Need to represent different auto completion impls
>> with different data source schemes. Currently impl
>> is OK for local address books but need to use a
>> server based query mechanism for other data sources.
>> Should auto-completion work across data source
>> domains? if so need an auto complete aggregator
>> perhaps?
>
>Having it work across multiple data sources would be a fine thing.
>Presumably RDF data sources could be used for this, and
>nsIRDFCompositeDataSource could be used to aggregate them. However,
>for this to work, all the data sources would probably need the same
>schema (or at least some subset of the schemas would have to be common).
>
Yes, could use the one already defined by the exisiting
'abdirectory:' and 'abcard:' RDF data sources, as suggested
previously.
>The LDAP RDF datasource that's in the tree is currently just
>scaffolding. Peter van der Beken (thanks Peter!) has done a bunch of
>work to flesh it out and get it basically working, and I hope to get
>this in the tree very soon. Then you'll be able to check out the
>existing schema.
>
Ok.
>> Query only data sources
>> Some LDAP sources will contain thousands of entries
>> thus only queries, with a limit on what is returned,
>> makes sense.
>> Users need to type in query to view returned list
>> (similar to auto complete?), like in Netscape 4.x
>> Need to cache result?
>
>In LDAPv3, at least, the Virtual List View extension is one way to get a
>small window into a large query result set. There's an IETF draft on
>this somewhere; I got my copy by pulling the OpenLDAP CVS tree and looking
>in the docs subdirectory. Caching might make sense, though I don't
>know if it's entirely necessary. Ultimately, we probably want to be
>able to replicate entire directories (or at least subsets) for offline
>use. But that should probably come later.
>
I agree offline can be done later on.
>> Card syntax and semantics
>> Perhaps it would be better to represent a card
>> using the vCard syntax and semantics? This
>> format seems to be more widely used esp. for
>> transmision over the internet. Recently an
>> LDAP draft has been updated:
>>
>> http://www.ietf.org/internet-drafts/draft-royer-vcard-ldap-00.txt
>>
>> which defines an LDAP schema for representing vCard.
>> We plan to use this in the web top server for
>> users' personal cards.
>> Its also easy to map personal information from the
>> inetOrgPerson scheme to vCard.
>>
>> http://docs.iplanet.com/docs/manuals/directory/41/gwcust/dsgwparm.htm#1041350
>>
>> However this may require many changes to the
>> existing impl and dependencies of, thus may not
>> justify the effort.
>
>This seems reasonable enough on the surface, but not yet having a good
>overview of the addressbook code, I can't guess how much work it might
>or might not take. As far as inetOrgPerson <-> vCard mapping, that's
>very cool.
>
Just hacked a different data source by re-implementing
some of the methods from the nsAbDirectory.cpp file, in
the process i had a moderate peruse through most of the
code. I really like the way mozilla uses RDF and the
association with data source and resource via URIs!
The existing card schema seems closely related to
inetOrgPerson, with a couple of extentions like the
attributes 'nickname' and 'usehtmlmail'. The RDF properties
for a card in addrbook/src/nsCardDataSource.cpp and the
attributes on the card interface addrbook/public/nsICard.idl
are essentially identical. Thus a change in the schema
affects alot of code, XUL and .js files.
Given these circumstances its probably better to have import/export
to vCard and allow for the dragging of a card as a mail
attachment which is sent as vCard and vice versa.
