[Kolab-devel] distributionlists testing

Bernhard Reiter bernhard at intevation.de
Thu May 22 11:26:37 CEST 2008


On Saturday 17 May 2008 08:03, Gunnar Wrobel wrote:
> Mike Gabriel <m.gabriel at das-netzwerkteam.de> writes:

> > yesterday, i faced an incompatibility problem between the horde
> > distlist code and the toltec distlist handling:
> >
> > the kolab format demands this MIME type for distlists (as implemented
> > in the new horde code fragments):
> > application/x-vnd.kolab.distribution-list
> >
> > toltec uses this MIME type... (??? this is not kolab xml format compliant
> > !!!) application/x-vnd.kolab.contact.distlist
>
> I tend to agree as the Kolab format says:
>
> The mimetype of this attachment will be
> "application/x-vnd.kolab.<type>" where type is the content type of the
> file.
> (http://kolab.org/doc/kolabformat-2.0rc7-html/x179.html)
>
> Looking at the Kontact source code on the other hand reveals that
> Kontact uses the same mime type :(

If this is the case, we might also consider changing the kolab-format spec
as we will have quite a few objects of this type out there in the wild.

> I can't give a definite answer here at the moment as this needs
> comments by other people. I think that following the Kolab format
> would make sense as it makes the implementation simpler. On the other
> hand the patch would be minor.
>
> > additionally, toltec adds another attachment of the MIME type:
> > application/x-outlook-tnef
> >
> > after decoding both toltec base64 encoded attachments, it seems like
> > the first (application/x-vnd.kolab.distribution-list) is fully kolab
> > xml format compliant (apart from the MIME type), and the latter adds
> > some binary stuff that helps to implement the full outlook address
> > book / distlist functionality into the kolab IMAP storage system.
>
> This is part of the Kolab format idea. Any client is allowed to add
> additional data to make the client work without problems. That is why
> I also just added the "uid" entries to the distlist. Other clients
> need to leave data they don't recognize intact.
>
> I did initially also believe that we should write everything into the
> Kolab format specs so that all clients can adhere to the specs. But I
> realized that the clients are too different to allow for that. You
> need some room for each client to cope with client specific needs or
> oddities.
>
> > thus for kolab, we have to adapt kolab to the toltec MIME type / agree
> > on a unique MIME type with the toltec people and see what happens, if:
> >
> >    1. a horde distlist is synced into outlook/toltec (and
> > viewed+edited+synced back)
> >    2. an outlook/toltec distlist is synced to kolab and viewed/edited
> > with horde and again synced back into outlook/toltec
>
> In the case of distlists I think it has become clear that there are
> still some features that are lacking and that could be easily
> supported by different clients. So it would be good to find some
> common ground there and put it in the specs. You should maybe start a
> discussion on kolab-format for that.
>
> > are there any toltec people listening to this thread???
>
> Joon definitely does.

On Monday 19 May 2008 10:28, Mike Gabriel wrote:
> Quoting Joon Radley <joon at radleys.co.za>:
> > Hi Mike,
> >
> > I will be looking into this and should have a resolution by next week.


-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/format/attachments/20080522/45036e92/attachment.sig>


More information about the format mailing list