I think it's valid XML if you encode non-ascii characters as &xFC; for an ü.

Yes, it makes sense if you know your user base and can judge what they 
are doing. I just think that for the general case having one Kolab 
client correcting data from another client might not be the best idea.
Is that a Horde bug? I had some utf-8 problems in XML myself lately. 
Maybe you can open another bug report or send a mail to kolab-dev.



Cheers,



Gunnar

Hello Gunnar,

Ok, that change is fine with me. I added the code to convert (old) 
broken data once the Horde client sees it. This would be useful if you 
restore old data from backups etc. Maybe I'll just leave it in my 
local copy, have to think about it a bit.



btw: Speaking of broken data, I'm in contact with Niko Berger who 
develops the Thunderbird Kolab plugin, looks like he fixed parsing 
umlauts generated from Horde which are XML-entities instead of utf-8 
:-) Will test it soon.



Thomas

In CVS, thanks.



The only thing I changed: I removed the "broken client" support. 
Rewriting the semicolon unconditionally to a comma seemed a little bit 
too limited to me. If it is really desired to support the broken 
notation we could probably do this depending on the product ID in the 
XML text.



Even if we would support the broken client notation I wonder if it 
makes much sense to rewrite the category entry within Horde then. Once 
the user connects with the broken client it would not understand the 
new category information, right?

That turned out to be a "bug" at my local installation:

I forgot to upgrade attributes.php :-)



Attached is a patch to preserve multiple Kolab categories

if the category of an object does not change.

Please requeue to "Kolab".



Thomas

Ok, looks like a bug in the Kolab implementation. I'll look into it.



Would it make sense if the Kolab driver sees an unknown (=new)

category to automatically add it?
Yeah, let's stabilize the release and then add more features :-)

I'll have to check if I can -reliable- preserve the multiple fields somehow.



Thomas

Right now the string category name is stored, not an array index.
It's done to make it clear what the category is, no matter what client 
is accessing the data.
Yeah, would be great to upgrade all Horde groupware apps to allow 
multiple categories - also known as tags? ;) - but I don't think it's 
productive to try and do that for the 3.2 releases.

Hello together,



I'm currently testing different Kolab clients playing together with Horde.

As far as I understood the internal data format of Prefs/CategoryManager.php,

all clients save the (array) id of a category in their data 
structures, regardless if you use a Kolab or SQL backend. Is that 
correct?



Wouldn't that make sharing the same set of categories between users impossible

for a shared calendar / addressbook?



Also Horde allows only one category f.e. for a contact. Kolab allows n 
categories.

Still have to think about a way to properly fix that, if possible.



Thomas