I want to write a carddav plugin for evolution and have some questions.
1) I'm a bit confused about how to implement the MKCOL in a UI
and how to represent child collections.
2) Somewhere in the spec it says you can have a parent
collection with child collections,
but the parent collections can't have any addressbook
items in it if it has any child collections. Is that right?
3) The carddav spec explains that, if SRV records are used, the client
should only need
A) the server-name (not URL)
B) the username and password,
then it should automatically select the 'default'
addressbook collection (e.g. Contacts) for the user's account.
This implies that any carddav server SHALL have SRV records for this
mode to work,
but the spec doesn't specifically REQUIRE SRV records for a carddav
server.
So, if there is no SRV record, how should the UI collect the URL
instead of just the server-name? There are disjoint concepts here.
4) In Evolution, I'm thinking that there should be a separate CardDAV
plugin
that asks for only the username and password,
then shows all of the visible collections, including public collections,
in a subtree under the carddav's addressbook entry
(in the left column list of addressbooks)
of course, it would only show collections that are actually of
addressbook type
5) Each collection (or addressbook) could have options
(as they do now, however they would be child-addressbooks
under the account), one of which would be selectable as
the default addressbook. By automatically adding all available
addressbooks,
a user won't have to add each addressbook individually.
Perhaps an option menu under the webdav-server entry
(parent to the subtree of collections) would allow a user
to select which addressbook collections to show or hide and
an option to automatically show new collections that are
available for instance when a different user gives you
access to see his or her addressbook.
6) If all of (5) sounds fine, then how do you handle nested
addressbooks:
child collections of children of the root.
Does davical support nested collections?
Should public, read-only, and writable addressbooks be shown in
separate groups under the CardDAV server entry (in the left column)?
7) I'm also unclear on how public addressbooks are to be handled.
Read-only carddav addressbooks also need to be supported,
at present evolution doesn't seem to handle read-only very
well other than erroring out when you try to make a change
to an entry in a read-only addressbook.
A) Should all public addressbooks appear under the subtree
alongside your private addressbooks if you are
authenticated with a server?
B) If you don't have a username and password on a server,
should the webdav plugin automatically show all
public addressbooks on a server?
8) How are username and password exchanged via CardDAV?
Is there any kind of hash used for the password
or is it sent cleartext if the server isn't using SSL?
>K
1) I'm a bit confused about how to implement the MKCOL in a UI
and how to represent child collections.
2) Somewhere in the spec it says you can have a parent
collection with child collections,
but the parent collections can't have any addressbook
items in it if it has any child collections. Is that right?
3) The carddav spec explains that, if SRV records are used, the client
should only need
A) the server-name (not URL)
B) the username and password,
then it should automatically select the 'default'
addressbook collection (e.g. Contacts) for the user's account.
This implies that any carddav server SHALL have SRV records for this
mode to work,
but the spec doesn't specifically REQUIRE SRV records for a carddav
server.
So, if there is no SRV record, how should the UI collect the URL
instead of just the server-name? There are disjoint concepts here.
4) In Evolution, I'm thinking that there should be a separate CardDAV
plugin
that asks for only the username and password,
then shows all of the visible collections, including public collections,
in a subtree under the carddav's addressbook entry
(in the left column list of addressbooks)
of course, it would only show collections that are actually of
addressbook type
5) Each collection (or addressbook) could have options
(as they do now, however they would be child-addressbooks
under the account), one of which would be selectable as
the default addressbook. By automatically adding all available
addressbooks,
a user won't have to add each addressbook individually.
Perhaps an option menu under the webdav-server entry
(parent to the subtree of collections) would allow a user
to select which addressbook collections to show or hide and
an option to automatically show new collections that are
available for instance when a different user gives you
access to see his or her addressbook.
6) If all of (5) sounds fine, then how do you handle nested
addressbooks:
child collections of children of the root.
Does davical support nested collections?
Should public, read-only, and writable addressbooks be shown in
separate groups under the CardDAV server entry (in the left column)?
7) I'm also unclear on how public addressbooks are to be handled.
Read-only carddav addressbooks also need to be supported,
at present evolution doesn't seem to handle read-only very
well other than erroring out when you try to make a change
to an entry in a read-only addressbook.
A) Should all public addressbooks appear under the subtree
alongside your private addressbooks if you are
authenticated with a server?
B) If you don't have a username and password on a server,
should the webdav plugin automatically show all
public addressbooks on a server?
8) How are username and password exchanged via CardDAV?
Is there any kind of hash used for the password
or is it sent cleartext if the server isn't using SSL?
>K