search

pimutils / vdirsyncer

📇 Synchronize calendars and contacts.
https://vdirsyncer.pimutils.org/
Other
1.53k stars 160 forks source link

RFC: Match by displayname, v2 #616

Open untitaker opened 7 years ago

untitaker commented 7 years ago

Problem

Discovery has been a huge UX pain since forever.

Solution

In that order, ideally all at once:

Later

This is massive breakage. I'm unsure how a migration strategy for users could look like. Just tell the user to set up vdirsyncer from scratch?

untitaker commented 7 years ago

Another reason for this idea is that currently two DAV collections who happen to have the same last path segment are treated as one collection in vdirsyncer. This behavior is potentially nondeterministic and theoretically may break with some DAV servers and Google. It could lead to a situation where two consecutive vdirsyncer discover runs would pair up different collections.

WhyNotHugo commented 7 years ago

filesystem: displayname == foldername for filesystem storage

Does this mean creating a directory named using the displayname fetched via metasync? Or the other way around?

untitaker commented 7 years ago

On Fri, Apr 07, 2017 at 10:33:59PM -0700, Hugo Osvaldo Barrera wrote:

filesystem: displayname == foldername for filesystem storage

Does this mean creating a directory named using the displayname fetched via metasync? Or the other way around?

It means that the folder is created with the displayname from the other side.

Also you would stop being able to sync displayname using metasync since it is now the key to pairing up collections.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/pimutils/vdirsyncer/issues/616#issuecomment-292696651

WhyNotHugo commented 7 years ago

Okay, that sounds perfect (I just wanted to make sure I'd understood correctly).

What's the fallback with collections where the remote server provides no displayname?

untitaker commented 7 years ago

I would fall back to the last URL segment again. Also we should have a storage param to always fall back.

untitaker commented 7 years ago

Not entirely sure anymore if this is a good idea. Pairing collections by a mutable property seems daring, but it appears that few alternatives exist.

geier commented 7 years ago

I'm actually not sure yet what you mean with your first point "We require users to know identifiers that are neither well-defined nor exposed in the UI of any other tool for CardDAV/CalDAV". Could you elaborate?

Regarding the second point: I don't think using displayname as a directory name is a good idea. I believe it shows again, that the standard wasn't made with tools like vdirsyncer in mind, but with applications that hide details like that internally. Apart from the allowed changes in their name, another potential problem could be that the standard allows different collections with the same displayname [0], but you could of course decide to just not support that case.

The RFC states that a collection is identified by its url [1], so one idea would be to use a hash of the URL as the directory name, which would make for pretty ugly dirnames though. On the other hand, how often are people going to modify vdirs by hand? A new command exporting the configured vdirs as json, including their displayname might be good enough for most tools to deal with that.

[0]

Clients SHOULD use the DAV:displayname property for a human-readable name of the calendar. Clients can either specify the value of the DAV:displayname property in the request body of the MKCALENDAR request, or alternatively issue a PROPPATCH request to change the DAV:displayname property to the appropriate value immediately after issuing the MKCALENDAR request. Clients SHOULD NOT set the DAV: displayname property to be the same as any other calendar collection at the same URI "level". When displaying calendar collections to users, clients SHOULD check the DAV:displayname property and use that value as the name of the calendar. In the event that the DAV: displayname property is empty, the client MAY use the last part of the calendar collection URI as the name; however, that path segment may be "opaque" and not represent any meaningful human-readable text.

[1]

4.2. Calendar Collection

A calendar collection contains calendar object resources that represent calendar components within a calendar. A calendar collection is manifested to clients as a WebDAV resource collection identified by a URL.