Page MenuHomekolab.org

Folder Hierarchy Merging and Flattening
Closed, ResolvedPublic

Description

With the switch from a white- to a black-list, Syncroton now (by default) synchronizes an IMAP-style hierarchy "as-is". This raises questions over the compatibility (read: user-friendliness and inherent intuitiveness to consuming clients such as Outlook 2013+ against Kolab);

  • A hierarchy (folders nested under other folders) may incur client behaviour that the sub-folder is available in the client only if the parent folder actually exists,
  • A hierarchy that is flattened (i.e. "Everything's a top-level folder") creates a significant risk of ending up with multiple top-level "Calendar" folders, all named the same, ... yeah...,
  • A merged hierarchy (the contents of every Calendar folder is merged to appear to reside in one single Calendar folder) is what we've been trying to move away from -- now that most newer clients do support multi-folder sources for their individual mail/calendar/contact client interfaces.

This ticket is intended to discuss and elaborate on the semantics under which we can both support a proper Kolab deployment yet allow users of clients incapable of dealing with certain inherent aspects of such Kolab deployment (i.e. an IMAP-style folder hierarchy, namespace roots, etc.) to have an enjoyable and intuitive experience.

Details

Ticket Type
Task

Event Timeline

It seems clear that folder merging (all folder's contents will appear to the client application as if they originate from a single folder) is far, far from the ideal solution. In part, T224 has been initiated with that in mind specifically, since more and more newer clients appeared to support multi-folder in their respective client implementations. We've therefore switched from needing to whitelist every such newer device, to instead blacklisting whatever older device we might choose to continue to support.

This still only concerns folder merging, though.

This ticket is about the improvement of user experience provided any of a variety of newer client applications, where we seem to have the following concerns;

  • Representing the native IMAP hierarchy (namespace roots, unsubscribed and non-existent parent folders) to client applications isn't a valid scenario for all client applications.
  • Flattening the hierarchy (i.e. pushing anything down a hierarchy to somehow be at the top of an emulated hierarchy) may create confusion if the hierarchy includes multiple folders bluntly named "Calendar".

These issues may need to be considered separately for different types of folders;

  • Mail folders
  • Event folders
  • Contact folders

The latter two may have a key-value lookup of /shared/vendor/cmu/cyrus-imapd/uniqueid -> 'display name' (use the key of uniqueid to prevent breaking on folder rename and hierarchical position changes). I suppose we could see:

`- Calendar                             (i.e. user/john.doe/Calendar@example.org)
`- Family Agenda                        (i.e. user/john.doe/Family Agenda@example.org)
`- Jane Doe's Calendar                  (i.e. user/jane.doe/Calendar@example.org, shared with john.doe@example.org causing it to appear to him as "Other Users/jane.doe/Calendar")
`- Jane Doe's Vacation Planning         (i.e. user/jane.doe/Vacation Planning@example.org, shared with john.doe@example.org causing it to appear to him as "Other Users/jane.doe/Vacation Planning")
`- Joe Sixpacks's Training Schedule     (i.e. same thing as before for a third user)

I could argue that such names can be automatically generated if not configured by the user themselves, or could be generated to override whatever the user may desire.

The former (Mail) is slightly more difficult, as mail tends to be sorted in to larger, deeper, more intrinsic hierarchies -- missing parents on any hierarchy is more likely to occur.

And again these issues may need to be considered separately for different folders;

  • Personal folders,
  • Other people's personal folders -- prefixed with an "Other Users" namespace prefix,
  • Shared folders -- normally prefixed with not only a generic "Shared Folders" namespaces prefix, but potentially spread across multiple namespaces (try kolab cm lists/this.is.fun@home).

And yet again, these issues may need to be considered for each of the following circumstances;

  • The folder is a sub-folder of a namespace root (i.e. "Other Users/jane.doe" where "Other Users/" is, in and by itself, considered to "not exist"),
  • The folder is a sub-folder of a non-existent parent (i.e. "Calendar/No Such/Yet Here's One" -- try it at home),
  • The folder is a sub-folder of an unsubscribed parent (i.e. "Calendar/Not Interesting/Secretly Really Interesting"),
  • Any full mesh combination of the above for as far as such is possible.

It seems most straight-forward to me to attempt to flatten the hierarchy to work around the majority of these issues, and engineer a way to name folders in such a way that the client can present the folders to the users in such a way that they are somewhat recognizable (i.e., why not make "Other Users/jane.doe/Calendar" appear as "Calendar (jane.doe)" or "jane.doe Calendar"?).

So long as we implement a routine that translates an original position in an IMAP hierarchy to something "top-level" in a way that prevents conflicts, and internally refers to such folder by uniqueid, we should be pretty safe on moving forward further with a /private/vendor/kolab/displayname implementation if so necessary, while allowing all clients to happily synchronize.

greve added a comment.Dec 7 2016, 7:02 PM

It seems most straight-forward to me to attempt to flatten the hierarchy to work around the majority of these issues, and engineer a way to name folders in such a way that the client can present the folders to the users in such a way that they are somewhat recognizable (i.e., why not make "Other Users/jane.doe/Calendar" appear as "Calendar (jane.doe)" or "jane.doe Calendar"?).

FWIW, I think "Shared Folders" and "Other Users" should indeed be thrown out for the name of the folder, as it is obvious and the information appears duplicate.

Often clients favour showing the right hand side of the information, so "Calendar (jane.doe)" would result in a long list of

... (jane.doe)
... (jane.doe)
... (jane.doe)
... (jane.doe)

with only these three characters available for the most relevant information (which folder is this?).

So I would prefer methodologies where the user name (or the "shared") is on the left hand side of the folder name.

As to how to do this, there is certainly many ways to skin that cat.

jane.doe Calendar/Subcalendar
jane.doe>Calendar/Subcalendar
jane.doe/Calendar/Subcalendar

would all work, and using a different separator between namespace/user and folder is probably good for the user to understand what they are looking at.

And because brackets need two characters for the same thing, I'd prefer not to use them. Let's keep this as short as possible.

petersen raised the priority of this task from 60 to High.Dec 19 2016, 5:15 PM

Raising priority of this and assigning (-oh - It's already assigned correctly)

machniak closed this task as Resolved.Dec 28 2016, 5:32 PM

Done. It does create folder names similar to these known from ActiveSync settings in Roundcube. Also iRony uses similar technique. So, the unification is good, but likely there's still a place for improvement. If we could agree on some precise unified format (with all corner cases described) we could then implement it for all of these three systems.