client compatibility (was: Re: [kroupware] About mozilla calendar ...)

[Bo Thorsen]

On Monday 20 January 2003 21:33, Henning Holtschneider wrote:
> --On Montag, 20. Januar 2003 19:44 +0100 Bo Thorsen <bo@sonofthor.dk>=20
wrote:
> >> format which can only be read by InsightConnector. So, if you start
> >> off under Windows and then wish to switch your client platform to
> >> Linux, you cannot transfer any other data than your emails.
> >
> > Why do you say this? We have been pretty succesful in decoding these.
> > At least appointments we can read just fine in the client.
>
> Sorry, I must have missed something here. Are you saying that you can
> decode the data  InsightConnector stores in "special" email messages on
> the server? 8-} I'm not talking about meeting requests sent to other
> clients, vCards or free/busy files.

Yes we can. Reading them is possible with a little reverse engineering,=20
and we have already done so for appointments. We might do so very soon=20
for tasks. Writing them is a much more difficult task though, but given=20
enough man years it can of course be done. Until the next Outlook version=20
comes along :-(

> > Why on earth do you want to reimplement Exchange with using the
> > proprietary fileformats we're all trying to get away from?
>
> No, that's NOT what I want. I want Outlook to speak a non-binary
> language on the storage side (=3D IMAP server, doesn't work at least for
> me; see below) and on the client-to-client communication side (=3D
> meeting requests etc.; works correctly)

If it's MAPI, it's proprietary. It's that simple. The problem you're=20
facing here is exactly the same as we're facing on the client side.=20
Outlook saves it's file on the server in tnef/mapi and there's nothing=20
you can do about that (please, oh please prove me wrong on this). The=20
reason the Bynari plugin works is that they are simply offering another=20
kind of storage than Exchange.

If you want to provide something that makes our life simpler, make a layer=
=20
between Bynari and Kolab. This layer will do the tnef/mapi <-> iCal=20
conversion. If this was the case, then KMail/KOrganizer and other clients=20
wouldn't be infected with tnef code but could worry only about the known=20
fileformat. When this is working, you can think about getting rid of=20
Bynari.

> > of the kolab server is orthogonal to what you want. We're focusing on
> > open standards, writing a client that supports them and getting
> > Outlook to work with it too.
>
> That's exactly what I tried to say ;-)
>
> I just checked the legacy file format specs in the architecture paper
> again and I think I'm probably making assumptions based on a broken or
> misconfigured InsightConnector. Another possibility would be that where
> the paper says "Legacy File Formats - Calendar Event" (Appendix B.1) it
> means "Meeting invitation".
>
> Here is my problem: the file format described in
> http://kolab.kde.org/concept-1.0.1/a566.html#AEN569 simply does not
> match what is being stored on the IMAP server by the InsightConnector.
> I've created a  sample calendar event and the event information is
> being stored in a binary attachment. You can download a sample at
> http://www.holtschneider.com/bynari-calendar.txt. I wrote my message to
> this mailing list based on that. If I'm too stupid to configure MS
> Outlook, please beat me up now ;*)

No, you're correct, and this is indeed a very big problem for us. If we=20
are going to succeed in offering the user the ability to work on both=20
KMKO and OL whenever you want, KMKO is forced to save tnef/mapi files. So=20
for now we focus on offering a migration path to KMKO by being able to=20
read these files but only save them as iCalendar - in effect rendering=20
them useless to OL.

> > P.S. Again I felt the need for some ranting. It is pretty annoying to
> > be part of a project when many of the mails send to the list lately
> > are all about why we should fundamentally do something different. So
> > I'd like future posters to this mailing list to actually *read* the
> > concept papers on www.kroupware.org and understand that the general
> > concept is not going to change. We are obviously happy with
> > discussing implementation details, but hearing someone elses thoughts
> > on how we should do most things different gets tiresome. If you want
> > to say that we're wrong, do it with
>
> I'm not telling you that your approach is wrong. In fact, I think it's
> right because it tries to use existing clients and doesn't try to
> program yet another client. Even more importantly, you will be
> delivering a working solution! That's a point where all other open
> groupware projects have failed so far because they have changed the
> specs over and over again or they have been working on stupid details
> but forgot the overall framework. I can't thank you guys enough for
> sticking to your goals!

Ok, I'm happy to have misunderstood you on these points :-)

Bo.

=2D-=20

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klar=E4lvdalens Datakonsult  |   Denmark