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.

In T2055#31554, @vanmeeuwen wrote:

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.