From bernhard at intevation.de Sat May 3 17:47:06 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Sat, 3 May 2008 17:47:06 +0200 Subject: 2.0rc7 -> 2.0 in two weeks In-Reply-To: <003b01c8aae1$e11dcfd0$a3596f70$@co.za> References: <200804181125.56872.bernhard@intevation.de> <200804301624.27805.bernhard@intevation.de> <003b01c8aae1$e11dcfd0$a3596f70$@co.za> Message-ID: <200805031747.07725.bernhard@intevation.de> Hi Joon, On Wednesday 30 April 2008 18:47, Joon Radley wrote: > We do a version check on the Kolab-XML and any version we do not understand > Toltec rejects. I thought that was the whole point of putting the version > in the Kolab-XML object :) sure it is, but ... :) Seriously from the spec somebody would assume and =1.0 and =2.0 would both be recoginised. Otherwise we never could do the change. Do you already have a version out that can do =2.0? what do you recomment regarding the release of the 2.0 spec? Add a special paragraph for "transition"? Best, Bernhard -- 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://kolab.org/pipermail/kolab-format/attachments/20080503/141c3847/attachment.bin From bernhard at intevation.de Sat May 3 21:12:06 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Sat, 3 May 2008 21:12:06 +0200 Subject: (new) xfb concept (draft) available Message-ID: <200805032112.11324.bernhard@intevation.de> Dear Kolab-Developers, from Kolab Server 2.1 to 2.2 we wanted to make better use of the extended Freebusy lists (xfbs) and solve the team overview use case. The xfbs have been invented for this use case originally. Internally we started with a new draft concept before implmentation, but unfortunately did not get around publishing it. (Originally Martin was to work on this, but he could not continue working on it so I took over this task and thus did not have time scheduled.) The document is still not finished, but in the best spirit of "publish early" I have put up a working copy here: https://ftp.intevation.de/users/bernhard/scratch/ md5sum 02911407f03f09575a312a9c834b36d5 extended-freebusy-concept-0.92+dev20080503-ber1-pub2.pdf WARNING: This is a working copy. It is subject to change! (You can see from the URL name "scratch", this version is likely to go away.) Comments are welcome, though this will probably only interesting to a few that want to follow this closely. Others will want to wait for a better draft, beta or release candidate version. Best, Bernhard -- 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://kolab.org/pipermail/kolab-format/attachments/20080503/215048f0/attachment.bin From joon at radleys.co.za Sun May 4 03:28:42 2008 From: joon at radleys.co.za (Joon Radley) Date: Sun, 4 May 2008 03:28:42 +0200 Subject: 2.0rc7 -> 2.0 in two weeks In-Reply-To: <200805031747.07725.bernhard@intevation.de> References: <200804181125.56872.bernhard@intevation.de> <200804301624.27805.bernhard@intevation.de> <003b01c8aae1$e11dcfd0$a3596f70$@co.za> <200805031747.07725.bernhard@intevation.de> Message-ID: <001e01c8ad86$344020e0$9cc062a0$@co.za> Hi Bernhard, Adding support for the version 2.0 version number support is trivial. Changing the version number however entails and upgrade of _all_ Kolab clients on all client machines. This is a major investment for what amounts to a clarification of the original Kolab-XML 1.0 specification. AFAIK all the clients are up to date with the current specification or very close to it, so changing the version number itself does not enforce anything. So we either must specify that version 2.0 is a completion of the 1.0 specification without a version number change or provide a change over period for clients with the "2.0" version number support to be incorporated in the normal upgrade cycle. Best Regards Joon Radley Radley Network Technologies CC Cell: +27 (0)83 368 8557 Fax: +27 (0)12 998 4346 E-mail: joon at radleys.co.za Web: www.toltec.co.za > -----Original Message----- > From: kolab-format-bounces at kolab.org [mailto:kolab-format- > bounces at kolab.org] On Behalf Of Bernhard Reiter > Sent: Saturday, May 03, 2008 5:47 PM > To: kolab-format at kolab.org > Subject: Re: 2.0rc7 -> 2.0 in two weeks > > Hi Joon, > > On Wednesday 30 April 2008 18:47, Joon Radley wrote: > > We do a version check on the Kolab-XML and any version we do not > > understand Toltec rejects. I thought that was the whole point of > > putting the version in the Kolab-XML object :) > > sure it is, but ... :) > > Seriously from the spec somebody would assume and =1.0 and =2.0 would > both be recoginised. Otherwise we never could do the change. Do you > already have a version out that can do =2.0? > > what do you recomment regarding the release of the 2.0 spec? Add a > special paragraph for "transition"? > > Best, > Bernhard > > > -- > 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 From bernhard at intevation.de Mon May 5 09:47:54 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 5 May 2008 09:47:54 +0200 Subject: 2.0rc7 -> 2.0 in two weeks In-Reply-To: <001e01c8ad86$344020e0$9cc062a0$@co.za> References: <200804181125.56872.bernhard@intevation.de> <200805031747.07725.bernhard@intevation.de> <001e01c8ad86$344020e0$9cc062a0$@co.za> Message-ID: <200805050947.55739.bernhard@intevation.de> Hi, On Sunday 04 May 2008 03:28, Joon Radley wrote: > Adding support for the version 2.0 version number support is trivial. > Changing the version number however entails and upgrade of _all_ Kolab > clients on all client machines. This is a major investment for what amounts > to a clarification of the original Kolab-XML 1.0 specification. according to our quick test the change would hit Toltec. (We did not test Konsec, nur Bynari. And it always has been the Kolab-Storage-Format 2.0 specification. ;) ) > AFAIK all the clients are up to date with the current specification or very > close to it, so changing the version number itself does not enforce > anything. > > So we either must specify that version 2.0 is a completion of the 1.0 > specification without a version number change or provide a change over > period for clients with the "2.0" version number support to be incorporated > in the normal upgrade cycle. I tend to go with the version=1.0 for the 2.0 specification, this deviates from the original idea, but I have doubts about the version=specification number. It would need to hold for development, beta and release candiate versions as well and there is the possibility of compatible changes. I propose to have a secion about compatibility in the document. Bernhard -- 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://kolab.org/pipermail/kolab-format/attachments/20080505/8e6184a0/attachment.bin From bernhard at intevation.de Thu May 22 11:26:37 2008 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 22 May 2008 11:26:37 +0200 Subject: [Kolab-devel] distributionlists testing In-Reply-To: <87od75jwmd.fsf@home.pardus.de> References: <20080418132326.953537gt046m8aem@mail.das-netzwerkteam.de> <20080516192210.107844o6rwg341c2@mail.das-netzwerkteam.de> <87od75jwmd.fsf@home.pardus.de> Message-ID: <200805221126.38253.bernhard@intevation.de> On Saturday 17 May 2008 08:03, Gunnar Wrobel wrote: > Mike Gabriel 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." 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 : > > 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://kolab.org/pipermail/kolab-format/attachments/20080522/45036e92/attachment.bin From martin.konold at erfrakon.de Mon May 26 09:21:46 2008 From: martin.konold at erfrakon.de (Martin Konold) Date: Mon, 26 May 2008 09:21:46 +0200 Subject: [Kolab-devel] distributionlists testing In-Reply-To: <200805221126.38253.bernhard@intevation.de> References: <20080418132326.953537gt046m8aem@mail.das-netzwerkteam.de> <87od75jwmd.fsf@home.pardus.de> <200805221126.38253.bernhard@intevation.de> Message-ID: <200805260921.50606.martin.konold@erfrakon.de> Am Donnerstag 22 Mai 2008 schrieb Bernhard Reiter: Hi, > > The mimetype of this attachment will be > > "application/x-vnd.kolab." 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 strongly object to this way of dealing with implementation problems. If the standard is not broken but the implementations are broken then fix the implementations but not the standard. The former approach is the reason for too many problem in other areas like html where implementations finally defined the standards... So fix the implementations and use the version numbering schema for backwards compatibility. Regards, -- martin konold -- e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Sitz: Adolfstra?e 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126 http://www.erfrakon.com/ From martin.konold at erfrakon.de Mon May 26 09:54:00 2008 From: martin.konold at erfrakon.de (Martin Konold) Date: Mon, 26 May 2008 09:54:00 +0200 Subject: Timezone issues Message-ID: <200805260954.05097.martin.konold@erfrakon.de> Hi, When entering a date e.g. for an event KDE Kontact should use (GMT+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm, Wien NOT (GMT+02:00) Amsterdam, Berlin, Bern, Rom, Stockholm, Wien even though we currently have DST in Germany. Rational: The timezone is solely dependend on the geographic location but not on the week. This is especially important for events spanning over DST switching sundays. E.g. a daily recurring event at 12 noon like "lunch" shall always happen at the same time and not be affected by daylight saving time switches. BTW: This is something which MS Outlook 2K3 does correct ;-) Mit freundlichen Gr??en, -- martin konold -- e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Sitz: Adolfstra?e 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126 http://www.erfrakon.com/