Kolab has the unique ability to allow for groupware objects (Calendars. Contacts, Tasks, Notes) to have a hierarchical structure, similar to an email account's folder structure, i.e. a Calendar can have a Sub-calendar, and the Sub-calendar can have a Sub-calendar too, and so on and so forth for other Groupware Objects.

This, I suppose, has arisen naturally out of Kolab's 'store all groupware data in IMAP approach", and as such every groupware folder can have a sub-object, as if it were a folder.

With next generation clients (Kube, Roundcube Next) being developed, I think it would be useful to evaluate the usefulness of hierarchical structure to groupware objects beyond mail folders, and whether or not this should remain. I think a user should not be limited to how many calendars, addressbooks etc, he wishes to have, but I think that these should remain all as equal objects and not children of other objects (i.e. that they remain on the same level).

It is definitely of mention that no other client beyond Kontact/Roundcube (Kolab-aware) client is able to understand/interpret this, hierarchical structure for groupware objects nor representable over modern protocols like CalDAV/CardDAV or ActiveSync and it is even playing out in issues like enabling of multiple calendar sync discussed here: https://git.kolab.org/T2055 (Folder Hierarchy Flattening and Merging).

With Kube going to be using CalDAV/CardDAV, how will it support these sub-objects (which I don't believe *DAV can support)? Maybe starting with Kube, it would be good to drop support for them, and similarly so with Roundcube Next, given that neither JMAP and *DAV offer a way to account for them. The modern clients could simply display these subjects as "Calendar >> SubCalendar" as CalDAV and CardDAV do currently, and when RCN eventually ships with a modern version of Kolab, Kontact and Roundcube can simply be rendered End Of Life.