AFAI am concerned, yes.

So, you're saying this can be closed then?

WebDAV/CalDAV which already happens to convert tags to iCalendar 
CATEGORIES attributes. We don't  synchronize them with Horde's tagging 
backend though, unlike the Kolab driver. And like in the Kolab driver, 
there is no performance gain if we need them to synchronize anyway.

These would  still be "only the drivers that use tags". The parameter 
is available to any driver that wants to make use of it. It's just 
that currently, only the SQL driver (and maybe Kolab - don't have code 
handy to look) actually fall under this category.

I would say that non-horde backends should only support tagging if the 
storage backend for the event itself understands them (be they called 
"tags" or "categories" or whatever). Otherwise, the user will be 
"surprised" when tags that were entered in Horde do not appear in the 
event data when accessed via another client. Otherwise, yes, I agree 
Besides SQL and Kolab, what backend do we support that would be 
considered read/write?

This is probably not quite correct, theoretically any driver could 
implement tagging, because the tags are stored independent from the 
calendar storage. At least all backends with read-write support should 
support tagging.

The latter is intentional by the way, because this is necessary to 
keep the tags between Horde's backend and the Kolab storage 
synchronized.

Well, only the drivers that actually use tags need this. That would be 
Sql and I guess Kolab. Are you saying basically that Tagging does not 
work currently with the Kolab driver, or only the ability to 
ignore|request them when calling listEvents?

Hi,

while debugging ticket #12160 I noticed that only the SQL driver 
implements the 'fetch_tags' feature.
All other drivers seem to silently ignore it.

The feature itself is exposed by the RPC API but it seems horde 
doesn't use it itself.
So it's more of a glitch.

Thomas