[Kolab-devel] horde AND kolab's private distribution lists
wrobel at pardus.de
Wed Mar 26 09:04:19 CET 2008
Mike Gabriel <m.gabriel at das-netzwerkteam.de> writes:
> hi gunnar,
> Quoting Mike Gabriel <m.gabriel at das-netzwerkteam.de>:
>> hi gunnar,
>> Quoting Gunnar Wrobel <wrobel at pardus.de>:
>>> Hi Mike,
>>> Mike Gabriel <m.gabriel at das-netzwerkteam.de> writes:
>>>> hi gunnar,
>>>> i would like to reintroduce the discussion about implementation of
>>>> kolab's private distribution lists into horde. to start this from
>>>> scratch seems to me as a rather big thing. could you give a hint on
>>>> where to look (mysql dist lists already exist in horde?) to start with
>>>> (as a template).
>>>> one of my customers repeatatively asks for private distribution lists,
>>>> so this might be a piece of work i might have to indulge in in the
>>>> near future...
>>> the dist-list format is defined within the Kolab format. It shouldn't
>>> be too hard to define a driver within Kolab/XML that handles the
>>> format correctly. What might be more difficult would be to find out
>>> how to map this into Horde. Without looking at the code I could
>>> imagine representing these list either as a Horde::Group, a
>>> Turba::vbook or Turba::favourites. But without looking at the code I'm
>>> currently unable to say which variant would be the correct one.
>> i looked at the turba code. the IMSP driver looks like it implements
>> distribution lists in a similar way as kolab does.
>> thus, the dist list has to go into the kolab driver(???).
>> i will look into things more closely.
> the night was long...
> i changed some lines in sources.php (kolab source) and by that i
> activated the distribution list feature for kolab that is already
> inherent in horde.
> i then found a restraint in your code (SORRY).
:D ... you'll find plenty of those if you work on the Horde::Kolab
module. I hope to be able to remove many of them once we move to Horde
4 but right now Horde is in a release phase and restructuring the
module is not possible. That does not affect this particular restraint
> you presume
> (getAppConsts) that each horde application can be bijectively mapped
> to a single xml/mime type (kronolith <-> xml kolab event, nag <-> xml
> kolab task, etc.)
I checked your solution now and we will have to modify it so that it
can be commited upstream.
> turba can - introducing distribution lists - now handle two xml/mime
> types. this breaks the cleanliness of code a bit.
> the current status now is:
> => i can add empty distribution lists with the correct kolab format in my
> contact folders
> what i still need to do:
> => add members to distribution lists
> for this, maybe you can help me:
> the Kolab_XML_distributionlist::_load($object) method receives an
> array that contains a string for the Turba_Objects of __members in the
> distribution list. is there an easy way in horde to turn a string like
> into the corresponding kolab objects? i know the long hashes are the
> UIDs of my kolab contacts / Turba_Objects. is there a function that
> cuts the string into its components? just trying to avoid to reinvent
> the wheel...
> das netzwerkteam
> mike gabriel, hamburger chaussee 240, 24113 kiel
> fon: +49 431 64 74 196
> voip/voicemail: +49 431 643 643 6
> fax: +49 431 64 74 276
> mail: m.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de
> Kolab-devel mailing list
> Kolab-devel at kolab.org
______ http://kdab.com _______________ http://kolab-konsortium.com _
p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de Dr. Gunnar Wrobel
Tel. : +49 700 6245 0000 Bundesstrasse 29
Fax : +49 721 1513 52322 D-20146 Hamburg
>> Mail at ease - Rent a kolab groupware server at p at rdus <<
More information about the devel