[Kolab-devel] CalDAV Collections vs. IMAP Folders

[Thomas Brüderli]

Thomas Brüderli wrote:
> Georg C. F. Greve wrote:
>> On 2013-03-20 09:12, Thomas Brüderli wrote:
>>> And what about sharing folders? If stored in /private/comment, how 
>>> would a
>>> folder appear to a sharee? If we use annotations for display names, we
>>> should consider to make that at least /shared/ with the option to set 
>>> a
>>> /private/ name on folders owned by others.
>> Indeed.
>>
>> Things I'd like to see considered:
>>
>>   - How will mail folders behave? I'm thinking being able to actually 
>> add a comment to them (think "pop-up help/comment to explain usage") 
>> might be useful. This might mean 'comment' should remain a comment (how 
>> is it defined for mail?) and so we might want to add an annotation 
>> /vendor/kolab/name, perhaps.
> 
> I'd vote for a specific annotation, too. And you're right, this feature can
> make sense for mail folders as well.
> 
> But I'd like to get back to the CalDAV/CardDAV realm. Here things are
> slightly different. While I assume for mail folders, we still maintain the
> folder hierarchy (just with custom names), hierarchy doesn't work in
> CalDAV. So the default display name for the folder
> "others/firstname.lastname/Calendar/Shared with Friends" in CalDAV would be
> something like "(firstname.lastname) Calendar » Shared with friends"
> according to our current rules. We can agree that the *DAV service
> automatically generates these display names unless there is a
> /private/vendor/kolab/name annotation present. That's fair enough for the
> display name topic.

Can we call this a final decision? Using a /vendor/kolab/name annotation
for display names and take the full IMAP path as UID for *DAV collections?

The consequence of the new display name logic is that we'll have a flat
(non-hierarchical) list of calendars, task lists and address books in the
web client, too. We basically have that already but the underlying folder
hierarchy is still reflected in the folder names. By letting a user
override the display name (either through DAV or directly in the web
client) will make that impossible. That's OK for me but I'd like to give
the defenders of the hierarchical lists a last chance to speak up :-)

Regards,
Thomas