From evolution@opengroupware.org Wed Aug 2 04:24:51 2006 From: evolution@opengroupware.org (Nick Papadonis) Date: Tue, 01 Aug 2006 23:24:51 -0400 Subject: [OGo-Evolution] Noodle/GroupDAV Connector? In-Reply-To: <1153369469.24598.7.camel@localhost.localdomain> References: <1153369469.24598.7.camel@localhost.localdomain> Message-ID: <1154489091.4940.2.camel@localhost.localdomain> On Thu, 2006-07-20 at 00:24 -0400, Nick Papadonis wrote: > Is anyone still working on this? > I guess not. Does anyone have the email addresses of past contributors? I'm hoping to avoid transitioning to HULA. Thanks From evolution@opengroupware.org Wed Aug 2 08:09:24 2006 From: evolution@opengroupware.org (Robert de Geus) Date: Wed, 02 Aug 2006 09:09:24 +0200 Subject: [OGo-Evolution] Noodle/GroupDAV Connector? In-Reply-To: <1154489091.4940.2.camel@localhost.localdomain> References: <1153369469.24598.7.camel@localhost.localdomain> <1154489091.4940.2.camel@localhost.localdomain> Message-ID: <1154502564.20275.9.camel@salsa-10-0-0-2> Hi, We have hired someone to fix the evolution_ogo connector. He is progressing very fast and we hope to be ready in a short time. After internal testing we will release the connector under GPL with respect to all people and organizations who have been working on the connector previously. The connector will then be compatible with evolution 2.6.1 running Ubuntu and zidestore 1.5 We can not say exactly when it will be ready and when we will release it, but everything looks very promising. regards, Robert de Geus Toltech Solutions B.V. Amsterdam The Netherlands On Tue, 2006-08-01 at 23:24 -0400, Nick Papadonis wrote: > On Thu, 2006-07-20 at 00:24 -0400, Nick Papadonis wrote: > > Is anyone still working on this? > > > > I guess not. Does anyone have the email addresses of past contributors? > > I'm hoping to avoid transitioning to HULA. > > Thanks > From evolution@opengroupware.org Wed Aug 2 10:34:25 2006 From: evolution@opengroupware.org (Helge Hess) Date: Wed, 2 Aug 2006 11:34:25 +0200 Subject: [OGo-Evolution] Noodle/GroupDAV Connector? In-Reply-To: <1154489091.4940.2.camel@localhost.localdomain> References: <1153369469.24598.7.camel@localhost.localdomain> <1154489091.4940.2.camel@localhost.localdomain> Message-ID: On Aug 2, 2006, at 05:24, Nick Papadonis wrote: > I'm hoping to avoid transitioning to HULA. Hm, where is the Hula connector? The CalDAV one? We will support that too, but CalDAV only does events. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From evolution@opengroupware.org Wed Aug 2 10:35:09 2006 From: evolution@opengroupware.org (Helge Hess) Date: Wed, 2 Aug 2006 11:35:09 +0200 Subject: [OGo-Evolution] Noodle/GroupDAV Connector? In-Reply-To: <1154502564.20275.9.camel@salsa-10-0-0-2> References: <1153369469.24598.7.camel@localhost.localdomain> <1154489091.4940.2.camel@localhost.localdomain> <1154502564.20275.9.camel@salsa-10-0-0-2> Message-ID: <5C265146-6718-4760-90D6-B7B6EA37D5F7@opengroupware.org> On Aug 2, 2006, at 09:09, Robert de Geus wrote: > We have hired someone to fix the evolution_ogo connector. Cool! :-) Thanks a lot, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From evolution@opengroupware.org Wed Aug 2 18:19:42 2006 From: evolution@opengroupware.org (Adam Tauno Williams) Date: Wed, 02 Aug 2006 13:19:42 -0400 Subject: [OGo-Evolution] Noodle/GroupDAV Connector? In-Reply-To: <1154502564.20275.9.camel@salsa-10-0-0-2> References: <1153369469.24598.7.camel@localhost.localdomain> <1154489091.4940.2.camel@localhost.localdomain> <1154502564.20275.9.camel@salsa-10-0-0-2> Message-ID: <1154539182.9252.0.camel@linux.site> > We have hired someone to fix the evolution_ogo connector. He is > progressing very fast and we hope to be ready in a short time. After > internal testing we will release the connector under GPL with respect to > all people and organizations who have been working on the connector > previously. The connector will then be compatible with evolution 2.6.1 > running Ubuntu and zidestore 1.5 > We can not say exactly when it will be ready and when we will release > it, but everything looks very promising. Awesome! From evolution@opengroupware.org Wed Aug 2 21:52:25 2006 From: evolution@opengroupware.org (Nick Papadonis) Date: Wed, 02 Aug 2006 16:52:25 -0400 Subject: [OGo-Evolution] Noodle/GroupDAV Connector? In-Reply-To: <1154502564.20275.9.camel@salsa-10-0-0-2> References: <1153369469.24598.7.camel@localhost.localdomain> <1154489091.4940.2.camel@localhost.localdomain> <1154502564.20275.9.camel@salsa-10-0-0-2> Message-ID: <1154551945.2437.0.camel@localhost.localdomain> On Wed, 2006-08-02 at 09:09 +0200, Robert de Geus wrote: > Hi, > We have hired someone to fix the evolution_ogo connector. He is > progressing very fast and we hope to be ready in a short time. After Wow! I look forward to your release. Thanks. From evolution@opengroupware.org Thu Aug 3 08:20:14 2006 From: evolution@opengroupware.org (Janosch Rolles) Date: Thu, 03 Aug 2006 09:20:14 +0200 Subject: [OGo-Evolution] Noodle/GroupDAV Connector? In-Reply-To: <1154551945.2437.0.camel@localhost.localdomain> References: <1153369469.24598.7.camel@localhost.localdomain> <1154489091.4940.2.camel@localhost.localdomain> <1154502564.20275.9.camel@salsa-10-0-0-2> <1154551945.2437.0.camel@localhost.localdomain> Message-ID: <1154589614.6027.0.camel@localhost> On Wed, 2006-08-02 at 16:52 -0400, Nick Papadonis wrote: > On Wed, 2006-08-02 at 09:09 +0200, Robert de Geus wrote: > > Hi, > > We have hired someone to fix the evolution_ogo connector. He is > > progressing very fast and we hope to be ready in a short time. After > > Wow! I look forward to your release. Thanks. > Me too. Thanks. From evolution@opengroupware.org Mon Aug 7 18:28:30 2006 From: evolution@opengroupware.org (Shreyas Srinivasan) Date: Mon, 7 Aug 2006 22:58:30 +0530 Subject: [OGo-Evolution] Improving the Ogo connector Message-ID: <8f8004410608071028h6de810abv2b0d902b74767c6b@mail.gmail.com> ------=_Part_59759_25428202.1154971710468 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hey, I am looking at porting and improving the ogo connector to work with evolution 2.[6,8]. I have been working on it for about a week now and have made a little progress. Calendar elements creation, edition and deletion works smoothly (it used to work i am told, i just fixed a couple of bugs). Now i am looking at fixing addressbook and tasks. My research showed that there was no way to create new addressbook elements as it was not supported by groupdav interface, has there been a change in status. Also i have a couple of doubts about the existing e-book-backend-ogo code, so if the original developers could help me out in explaining a little of the code(only a couple of questions), i would be grateful. I have some experience in working with evolution as i used to maintain the evolution mailer and the mac osx port when i was at Novell. I am attaching a diff of the work i have done so far (diff'ed against evolution head), its not much but i hope to do a lot more. Hopefully if i can understand the current connector code base well, i can work on extending it to current opengroupware feature compatibility and also work on some stability work. Looking forward to hearing from all of you. Thanks, Shreyas -- CelAbrate your flaws ------=_Part_59759_25428202.1154971710468 Content-Type: application/octet-stream; name=update-ogo.diff Content-Transfer-Encoding: base64 X-Attachment-Id: f_eql48g4t Content-Disposition: attachment; filename="update-ogo.diff" LS0tIC9ob21lL3NzaHJleWFzL2JsZWgvZXZvbHV0aW9uLWdyb3VwZGF2LTAuMi9jb25maWd1cmUu aW4JMjAwNS0wMy0wNyAwMToxMDo0MC4wMDAwMDAwMDAgKzA1MzAKKysrIGNvbmZpZ3VyZS5pbgky MDA2LTA3LTI1IDIyOjM3OjU2LjAwMDAwMDAwMCArMDUzMApAQCAtMTgsNyArMTgsMTAgQEAgQU1f UEFUSF9HTElCXzJfMAogCiBPR09fQ09NUElMRV9XQVJOSU5HUwogCi1BQ19QUk9HX0lOVExUT09M KFswLjMwXSkKK2RubCBBQ19QUk9HX0lOVExUT09MKFswLjM1LjBdKQorZG5sIEkxOE4gc3R1ZmYK K0lUX1BST0dfSU5UTFRPT0woWzAuMzUuMF0pCisKIAogQUNfUEFUSF9QUk9HKFBLR19DT05GSUcs IHBrZy1jb25maWcsIG5vKQogaWYgdGVzdCB4JFBLR19DT05GSUcgPSB4bm8gOyB0aGVuCkBAIC04 Myw3ICs4Niw3IEBAIFBLR19DSEVDS19NT0RVTEVTKEVWT0dST1VQREFWLAogICAgIAlsaWJlYm9v ay0kRURTX1BBQ0tBR0UgPj0gJEVEU19SRVFVSVJFRAogCWxpYmVkYXRhLWNhbC0kRURTX1BBQ0tB R0UgPj0gJEVEU19SRVFVSVJFRAogCWNhbWVsLXByb3ZpZGVyLSRFRFNfUEFDS0FHRSA+PSAkRURT X1JFUVVJUkVECi0JZXZvbHV0aW9uLXBsdWdpbi0yLjIKKwlldm9sdXRpb24tcGx1Z2luLTIuOAog XSkKIAogQUNfU1VCU1QoRVZPR1JPVVBEQVZfQ0ZMQUdTKQpAQCAtMTEwLDcgKzExMyw3IEBAIGRu bCB4QUNfU1VCU1QoRVZPTFVUSU9OX1NPVVJDRSkKIGRubCBFdm9sdXRpb24gcGx1Z2luIGluc3Rh bGwgZGlyZWN0b3J5CiBBQ19BUkdfV0lUSChwbHVnaW4taW5zdGFsbC1kaXIsIFsgIC0td2l0aC1w bHVnaW4taW5zdGFsbC1kaXI9UEFUSCBwYXRoIHRvIGV2b2x1dGlvbiBzb3VyY2UgdHJlZV0pCiBp ZiB0ZXN0ICJ4JHdpdGhfcGx1Z2luX2luc3RhbGxfZGlyIiA9ICJ4IiA7IHRoZW4KLSAgIFBMVUdJ Tl9JTlNUQUxMX0RJUj1gcGtnLWNvbmZpZyAtLXZhcmlhYmxlPXBsdWdpbmRpciBldm9sdXRpb24t cGx1Z2luLTIuMmAKKyAgIFBMVUdJTl9JTlNUQUxMX0RJUj1gcGtnLWNvbmZpZyAtLXZhcmlhYmxl PXBsdWdpbmRpciBldm9sdXRpb24tcGx1Z2luLTIuOGAKICAgIGlmIHRlc3QgIngkUExVR0lOX0lO U1RBTExfRElSIiA9ICJ4IjsgdGhlbgogICAgICAgQUNfTVNHX0VSUk9SKFVuYWJsZSB0byBmaW5k IHBsdWdpbiBkaXJlY3RvcnkpCiAgICBmaQpAQCAtMTE4LDMwICsxMjEsMTIgQEAgZmkKIEFDX1NV QlNUKFBMVUdJTl9JTlNUQUxMX0RJUikKIAogZG5sIEV2b2x1dGlvbiBlLWVycm9yIGluc3RhbGwg ZGlyZWN0b3J5Ci1FUlJPUl9ESVI9YHBrZy1jb25maWcgLS12YXJpYWJsZT1lcnJvcmRpciBldm9s dXRpb24tcGx1Z2luLTIuMmAKK0VSUk9SX0RJUj1gcGtnLWNvbmZpZyAtLXZhcmlhYmxlPWVycm9y ZGlyIGV2b2x1dGlvbi1wbHVnaW4tMi44YAogaWYgdGVzdCAieCRFUlJPUl9ESVIiID0gIngiOyB0 aGVuCiAgICBBQ19NU0dfRVJST1IoVW5hYmxlIHRvIGZpbmQgZXJyb3IgZmlsZSBkaXJlY3Rvcnkp CiBmaQogQUNfU1VCU1QoRVJST1JfRElSKQogCi1kbmwgIC0tLS0tLS0tLS0tLS0tLS0tLQotZG5s IHwgTGFuZ3VhZ2UgU3VwcG9ydCB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tCi1kbmwgIC0tLS0tLS0tLS0tLS0tLS0tLQotR0VUVEVYVF9QQUNLQUdFPWV2b2x1dGlvbi1n cm91cGRhdgotQUNfU1VCU1QoR0VUVEVYVF9QQUNLQUdFKQotQUNfREVGSU5FX1VOUVVPVEVEKEdF VFRFWFRfUEFDS0FHRSwgIiRHRVRURVhUX1BBQ0tBR0UiLCBbVGhlIHByZWZpeCBmb3Igb3VyIGdl dHRleHQgdHJhbnNsYXRpb24gZG9tYWlucy5dKQotCi1kbmwgQUxMX0xJTkdVQVM9ImFtIGF6IGJl IGJnIGNhIGNzIGRhIGRlIGVsIGVuX0NBIGVuX0dCIGVzIGV0IGZhIGZyIGhpIGhyIGh1IGlkIGlz IGl0IGphIGtuIGtvIGx2IG1sIG1uIG1zIG5iIG5sIG5uIG5vIHBhIHBsIHB0IHB0X0JSIHJ1IHNr IHNxIHNyIHNyQExhdG4gc3YgdWsgemhfQ04gemhfVFciCi0KLUFNX0dMSUJfR05VX0dFVFRFWFQK LQotaWYgdGVzdCAieCRwcmVmaXgiID0gInhOT05FIjsgdGhlbgotICBHTk9NRUxPQ0FMRURJUj0k YWNfZGVmYXVsdF9wcmVmaXgvJHtEQVRBRElSTkFNRX0vbG9jYWxlCi1lbHNlCi0gIEdOT01FTE9D QUxFRElSPSRwcmVmaXgvJHtEQVRBRElSTkFNRX0vbG9jYWxlCi1maQotQUNfREVGSU5FX1VOUVVP VEVEKEdOT01FTE9DQUxFRElSLCAiJEdOT01FTE9DQUxFRElSIiwgW1RoZSBsb2NhbGUgZGlyIHRv IHVzZV0pCi0KIGRubCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQogCiBkbmwgVGhpcyB3aWxsIGNhdXNlIHRoZSBhdXRvbWFrZSBnZW5l cmF0ZWQgbWFrZWZpbGVzIHRvIHBhc3MgdGhlCi0tLSAvZGV2L251bGwJMjAwNi0wNy0yNSAxMDox OTowOS40MzE3NTIwMDAgKzA1MzAKKysrIGF1dG9nZW4uc2gJMjAwNi0wNy0yNSAyMDo1NjoyNS4w MDAwMDAwMDAgKzA1MzAKQEAgLTAsMCArMSwyMiBAQAorIyEvYmluL3NoCisjIFJ1biB0aGlzIHRv IGdlbmVyYXRlIGFsbCB0aGUgaW5pdGlhbCBtYWtlZmlsZXMsIGV0Yy4KKworc3JjZGlyPWBkaXJu YW1lICQwYAordGVzdCAteiAiJHNyY2RpciIgJiYgc3JjZGlyPS4KKworUEtHX05BTUU9ImV2b2x1 dGlvbi1vZ28tY29ubmVjdG9yIgorUkVRVUlSRURfQVVUT01BS0VfVkVSU0lPTj0xLjYKKworKHRl c3QgLWYgJHNyY2Rpci9jb25maWd1cmUuaW4gXAorICAmJiB0ZXN0IC1mICRzcmNkaXIvQ2hhbmdl TG9nIFwKKyAgJiYgdGVzdCAtZCAkc3JjZGlyL2NhbGVuZGFyKSB8fCB7CisgICAgZWNobyAtbiAi KipFcnJvcioqOiBEaXJlY3RvcnkgIlxgJHNyY2RpclwnIiBkb2VzIG5vdCBsb29rIGxpa2UgdGhl IgorICAgIGVjaG8gIiB0b3AtbGV2ZWwgJFBLR19OQU1FIGRpcmVjdG9yeSIKKyAgICBleGl0IDEK K30KKword2hpY2ggZ25vbWUtYXV0b2dlbi5zaCB8fCB7CisgICAgZWNobyAiWW91IG5lZWQgdG8g aW5zdGFsbCBnbm9tZS1jb21tb24gZnJvbSB0aGUgR05PTUUgQ1ZTIgorICAgIGV4aXQgMQorfQor VVNFX0dOT01FMl9NQUNST1M9MSAuIGdub21lLWF1dG9nZW4uc2gKLS0tIC9kZXYvbnVsbAkyMDA2 LTA3LTI1IDEwOjE5OjA5LjQzMTc1MjAwMCArMDUzMAorKysgcG8vTElOR1VBUwkyMDA2LTA3LTI1 IDIyOjQ4OjU3LjAwMDAwMDAwMCArMDUzMApAQCAtMCwwICsxLDQgQEAKKyNwbGVhc2Uga2VlcCB0 aGlzIGxpc3QgYWxwaGFiZXRpY2FsbHkgc29ydGVkCisjCisjYW0gYXogYmUgYmcgY2EgY3MgZGEg ZGUgZWwgZW5fQ0EgZW5fR0IgZXMgZXQgZmEgZnIgaGkgaHIgaHUgaWQgaXMgaXQgamEga24KKyNr byBsdiBtbCBtbiBtcyBuYiBubCBubiBubyBwYSBwbCBwdCBwdF9CUiBydSBzayBzcSBzciBzckBM YXRuIHN2IHVrIHpoX0NOIHpoX1RXCi0tLSAvaG9tZS9zc2hyZXlhcy9ibGVoL2V2b2x1dGlvbi1n cm91cGRhdi0wLjIvY2FsZW5kYXIvZS1jYWwtYmFja2VuZC1vZ28uYwkyMDA1LTAyLTI1IDA3OjUw OjQ4LjAwMDAwMDAwMCArMDUzMAorKysgY2FsZW5kYXIvZS1jYWwtYmFja2VuZC1vZ28uYwkyMDA2 LTA3LTI1IDIwOjQ3OjU2LjAwMDAwMDAwMCArMDUzMApAQCAtNDUsNiArNDUsNyBAQCBzdHJ1Y3Qg X0VDYWxCYWNrZW5kT0dvUHJpdmF0ZSB7CiAKIAlnY2hhciAqdXNlcm5hbWU7CiAJZ2NoYXIgKnBh c3N3b3JkOworCWdjaGFyICp1c2VyX2VtYWlsOwogfTsKIAogc3RhdGljIEVDYWxCYWNrZW5kQ2xh c3MgKnBhcmVudF9jbGFzcyA9IE5VTEw7CkBAIC04Nyw5ICs4OCwyMiBAQCBlX2NhbF9iYWNrZW5k X29nb19pc19yZWFkX29ubHkgKEVDYWxCYWNrCiBzdGF0aWMgRUNhbEJhY2tlbmRTeW5jU3RhdHVz CiBlX2NhbF9iYWNrZW5kX29nb19nZXRfY2FsX2FkZHJlc3MgKEVDYWxCYWNrZW5kU3luYyAqYmFj a2VuZCwgRURhdGFDYWwgKmNhbCwgY2hhciAqKmFkZHJlc3MpCiB7Ci0JZ193YXJuaW5nICgiJXM6 IGltcGxlbWVudCBtZSEiLCBfX1BSRVRUWV9GVU5DVElPTl9fKTsKKwlFQ2FsQmFja2VuZE9HbyAq b2dvOworCUVDYWxCYWNrZW5kT0dvUHJpdmF0ZSAqcHJpdjsKIAotCXJldHVybiBHTk9NRV9Fdm9s dXRpb25fQ2FsZW5kYXJfT3RoZXJFcnJvcjsKKwlvZ28gPSBFX0NBTF9CQUNLRU5EX09HTyhiYWNr ZW5kKTsKKwlwcml2ID0gb2dvLT5wcml2OyAKKworCWlmIChwcml2LT5tb2RlID09IENBTF9NT0RF X1JFTU9URSkgeworCQlpZiAocHJpdi0+dXNlcl9lbWFpbCkKKwkJCWdfZnJlZSAocHJpdi0+dXNl cl9lbWFpbCk7CisKKwkJcHJpdi0+dXNlcl9lbWFpbCA9IGdfc3RyZHVwIChlX29nb19jb25uZWN0 aW9uX2dldF91c2VyX2VtYWlsIChvZ28tPnByaXYtPmNvbm4pKTsKKwl9CisKKwkqYWRkcmVzcyA9 IGdfc3RyZHVwIChwcml2LT51c2VyX2VtYWlsKTsKKworCXJldHVybiBHTk9NRV9Fdm9sdXRpb25f Q2FsZW5kYXJfU3VjY2VzczsKIH0KIAogc3RhdGljIEVDYWxCYWNrZW5kU3luY1N0YXR1cwpAQCAt Mzc3LDE0ICszOTEsMTYgQEAgdXBkYXRlX2RlbHRhcyAoRUNhbEJhY2tlbmRPR28gKm9nbywgY29u cwogCQkJdnR5cGUgPSBlX2NhbF9jb21wb25lbnRfZ2V0X3Z0eXBlIChjb21wKTsKIAkJCWlmICgo dnR5cGUgPT0gRV9DQUxfQ09NUE9ORU5UX0VWRU5UKSB8fAogCQkJICAgICh2dHlwZSA9PSBFX0NB TF9DT01QT05FTlRfVE9ETykpIHsKLQkJCQllX2NhbF9jb21wb25lbnRfZ2V0X3VpZCAoY29tcCwg JnVpZCk7CisJCQkJRUNhbENvbXBvbmVudElkICppZCA9IGVfY2FsX2NvbXBvbmVudF9nZXRfaWQg KGNvbXApOwogCQkJCQorCQkJCWlmIChlX2NhbF9iYWNrZW5kX2NhY2hlX3JlbW92ZV9jb21wb25l bnQgKHByaXYtPmNhY2hlLCBpZC0+dWlkLCBpZC0+cmlkKSkgewogCQkJCWNvbXBfc3RyID0gZV9j YWxfY29tcG9uZW50X2dldF9hc19zdHJpbmcgKGNvbXApOwogCQkJCWVfY2FsX2JhY2tlbmRfbm90 aWZ5X29iamVjdF9yZW1vdmVkIChFX0NBTF9CQUNLRU5EIChvZ28pLCAKLQkJCQkJCQkJICAgICAo Y2hhciAqKSB1aWQsIGNvbXBfc3RyLCBOVUxMKTsKLQkJCQllX2NhbF9iYWNrZW5kX2NhY2hlX3Jl bW92ZV9jb21wb25lbnQgKG9nby0+cHJpdi0+Y2FjaGUsIChjb25zdCBjaGFyICopIHVpZCwgTlVM TCk7CisJCQkJCQkJCQkgICAgIGlkLCBjb21wX3N0ciwgTlVMTCk7CisJCQkJCWVfY2FsX2NvbXBv bmVudF9mcmVlX2lkIChpZCk7CiAJCQkJZ19mcmVlIChjb21wX3N0cik7CiAJCQl9CisJCQl9CiAK IAkJfSBlbHNlIGlmIChzdHJjbXAgKGV0YWcsIGNhY2hlZF9ldGFnKSAhPSAwKSB7CiAJCQl1cGRh dGVkX2l0ZW1zID0gZ19saXN0X3ByZXBlbmQgKHVwZGF0ZWRfaXRlbXMsIHJlYWxfaHJlZik7CkBA IC02NjUsMTMgKzY4MSwxMyBAQCBlX2NhbF9iYWNrZW5kX29nb19nZXRfbGRhcF9hdHRyaWJ1dGUg KEVDCiBzdGF0aWMgRUNhbEJhY2tlbmRTeW5jU3RhdHVzCiBlX2NhbF9iYWNrZW5kX29nb19nZXRf c3RhdGljX2NhcGFiaWxpdGllcyAoRUNhbEJhY2tlbmRTeW5jICpiYWNrZW5kLCBFRGF0YUNhbCAq Y2FsLCBjaGFyICoqY2FwYWJpbGl0aWVzKQogewotCSpjYXBhYmlsaXRpZXMgPSBnX3N0cmR1cCAo Q0FMX1NUQVRJQ19DQVBBQklMSVRZX05PX0VNQUlMX0FMQVJNUyAiLCIgXAotCQkJCSAgQ0FMX1NU QVRJQ19DQVBBQklMSVRZX09ORV9BTEFSTV9PTkxZICIsIiBcCi0JCQkJICBDQUxfU1RBVElDX0NB UEFCSUxJVFlfUkVNT1ZFX0FMQVJNUyAiLCIgICBcCi0JICAgICAgICAgICAgICAgICAgICAgICAg ICBDQUxfU1RBVElDX0NBUEFCSUxJVFlfTk9fVEhJU0FORFBSSU9SICIsIiBcCi0JCQkJICBDQUxf U1RBVElDX0NBUEFCSUxJVFlfTk9fVEhJU0FOREZVVFVSRSAiLCIgXAotCQkJCSAgQ0FMX1NUQVRJ Q19DQVBBQklMSVRZX05PX0NPTlZfVE9fQVNTSUdOX1RBU0sgIiwiIFwKLQkJCQkgIENBTF9TVEFU SUNfQ0FQQUJJTElUWV9OT19DT05WX1RPX1JFQ1VSICIsIiBcCisJKmNhcGFiaWxpdGllcyA9IGdf c3RyZHVwIChDQUxfU1RBVElDX0NBUEFCSUxJVFlfTk9fRU1BSUxfQUxBUk1TICIsIiAKKwkJCQkg IENBTF9TVEFUSUNfQ0FQQUJJTElUWV9PTkVfQUxBUk1fT05MWSAiLCIgCisJCQkJICBDQUxfU1RB VElDX0NBUEFCSUxJVFlfUkVNT1ZFX0FMQVJNUyAiLCIKKwkgICAgICAgICAgICAgICAgICAgICAg ICAgIENBTF9TVEFUSUNfQ0FQQUJJTElUWV9OT19USElTQU5EUFJJT1IgIiwiCisJCQkJICBDQUxf U1RBVElDX0NBUEFCSUxJVFlfTk9fVEhJU0FOREZVVFVSRSAiLCIKKwkJCQkgIENBTF9TVEFUSUNf Q0FQQUJJTElUWV9OT19DT05WX1RPX0FTU0lHTl9UQVNLICIsIgorCQkJCSAgQ0FMX1NUQVRJQ19D QVBBQklMSVRZX05PX0NPTlZfVE9fUkVDVVIgIiwiCiAJCQkJICBDQUxfU1RBVElDX0NBUEFCSUxJ VFlfU0FWRV9TQ0hFRFVMRVMpOwogCiAJcmV0dXJuIEdOT01FX0V2b2x1dGlvbl9DYWxlbmRhcl9T dWNjZXNzOwpAQCAtNjk4LDYgKzcxNCw3IEBAIGVfY2FsX2JhY2tlbmRfb2dvX2NyZWF0ZV9vYmpl Y3QgKEVDYWxCYWMKIHsKIAlFQ2FsQmFja2VuZE9HbyAqb2dvOwogCUVDYWxCYWNrZW5kT0dvUHJp dmF0ZSAqcHJpdjsKKwlFQ2FsQ29tcG9uZW50SWQgKmlkOwogCWljYWxjb21wb25lbnQgKmljYWxj b21wLCAqY2FsZW5kYXI7CiAJZ2NoYXIgKnVyaTsKIAlPR29Db25uZWN0aW9uU3RhdHVzIHN0YXR1 czsKQEAgLTcwOSwxMSArNzI2LDE0IEBAIGVfY2FsX2JhY2tlbmRfb2dvX2NyZWF0ZV9vYmplY3Qg KEVDYWxCYWMKIAlvZ28gPSBFX0NBTF9CQUNLRU5EX09HTyAoYmFja2VuZCk7CiAJcHJpdiA9IG9n by0+cHJpdjsKIAorCWZwcmludGYgKHN0ZGVyciwiJXNcbiIsICJlX2NhbF9iYWNrZW5kX29nb19j cmVhdGVfb2JqZWN0Iik7CiAJLyogRklYTUU6IFdlIG9ubHkgc3VwcG9ydCBldmVudHMgcmlnaHQg bm93ICovCisJLyogamFub3NjaDogbGV0cyB0cnkgaW5zZXJ0aW5nIHRhc2tzLi4uCiAJaWYgKGVf Y2FsX2JhY2tlbmRfZ2V0X2tpbmQgKEVfQ0FMX0JBQ0tFTkQgKGJhY2tlbmQpKSA9PSBJQ0FMX1ZU T0RPX0NPTVBPTkVOVCkgewogCQllX2NhbF9iYWNrZW5kX25vdGlmeV9lcnJvciAoRV9DQUxfQkFD S0VORCAoYmFja2VuZCksIF8oIkN1cnJlbnRseSwgY3JlYXRpbmcgbmV3IHRhc2tzIGlzIHVuc3Vw cG9ydGVkIikpOwogCQlyZXR1cm4gR05PTUVfRXZvbHV0aW9uX0NhbGVuZGFyX090aGVyRXJyb3I7 CiAJfQorCSovCiAJCiAJLyogY2hlY2sgdGhlIGNvbXBvbmVudCBmb3IgdmFsaWRpdHkgKi8KIAlp Y2FsY29tcCA9IGljYWxwYXJzZXJfcGFyc2Vfc3RyaW5nICgqY2Fsb2JqKTsKQEAgLTc0NCw4ICs3 NjQsOSBAQCBlX2NhbF9iYWNrZW5kX29nb19jcmVhdGVfb2JqZWN0IChFQ2FsQmFjCiAJICAgCiAJ ZV9jYWxfYmFja2VuZF9ub3RpZnlfb2JqZWN0X2NyZWF0ZWQgKEVfQ0FMX0JBQ0tFTkQgKG9nbyks ICpjYWxvYmopOwogCWNvbXAgPSBlX2NhbF9jb21wb25lbnRfbmV3X2Zyb21fc3RyaW5nICgqY2Fs b2JqKTsKLQllX2NhbF9jb21wb25lbnRfZ2V0X3VpZCAoY29tcCwgJnRtcCk7Ci0JZV9jYWxfYmFj a2VuZF9ub3RpZnlfb2JqZWN0X3JlbW92ZWQgKEVfQ0FMX0JBQ0tFTkQgKG9nbyksIHRtcCwgKmNh bG9iaiwgTlVMTCk7CisJaWQgPSBlX2NhbF9jb21wb25lbnRfZ2V0X2lkIChjb21wKTsKKwllX2Nh bF9iYWNrZW5kX25vdGlmeV9vYmplY3RfcmVtb3ZlZCAoRV9DQUxfQkFDS0VORCAob2dvKSwgaWQs ICpjYWxvYmosIE5VTEwpOworCWVfY2FsX2NvbXBvbmVudF9mcmVlX2lkIChpZCk7CiAJZ19vYmpl Y3RfdW5yZWYgKGNvbXApOwogCQogCS8qIFJlLWZldGNoIHRoZSBpdGVtICovCkBAIC03NzYsMTAg Kzc5NywxMyBAQCBlX2NhbF9iYWNrZW5kX29nb19tb2RpZnlfb2JqZWN0IChFQ2FsQmFjCiAJZ2No YXIgKm5ld19jb250ZW50czsKIAogCS8qIEZJWE1FOiBXZSBvbmx5IHN1cHBvcnQgZXZlbnRzIHJp Z2h0IG5vdyAqLworCS8qIGphbm9zY2g6IGxldHMgdHJ5IHVwZGF0aW5nIHRhc2tzLi4uCiAJaWYg KGVfY2FsX2JhY2tlbmRfZ2V0X2tpbmQgKEVfQ0FMX0JBQ0tFTkQgKGJhY2tlbmQpKSA9PSBJQ0FM X1ZUT0RPX0NPTVBPTkVOVCkgewogCQllX2NhbF9iYWNrZW5kX25vdGlmeV9lcnJvciAoRV9DQUxf QkFDS0VORCAoYmFja2VuZCksIF8oIkN1cnJlbnRseSwgbW9kaWZ5aW5nIHRhc2tzIGlzIHVuc3Vw cG9ydGVkIikpOwogCQlyZXR1cm4gR05PTUVfRXZvbHV0aW9uX0NhbGVuZGFyX090aGVyRXJyb3I7 CiAJfQorCSovCisJCiAJCiAJKm9sZF9vYmplY3QgPSBOVUxMOwogCQpAQCAtODczLDYgKzg5Nyw3 IEBAIGVfY2FsX2JhY2tlbmRfb2dvX3JlbW92ZV9vYmplY3QgKEVDYWxCYWMKIHN0YXRpYyBFQ2Fs QmFja2VuZFN5bmNTdGF0dXMKIGVfY2FsX2JhY2tlbmRfb2dvX2Rpc2NhcmRfYWxhcm0gKEVDYWxC YWNrZW5kU3luYyAqYmFja2VuZCwgRURhdGFDYWwgKmNhbCwgY29uc3QgY2hhciAqdWlkLCBjb25z dCBjaGFyICphdWlkKQogeworCWZwcmludGYgKHN0ZGVyciwiJXNcbiIsICJlX2NhbF9iYWNrZW5k X29nb19kaXNjYXJkX2FsYXJtIik7CiAJcmV0dXJuIEdOT01FX0V2b2x1dGlvbl9DYWxlbmRhcl9P dGhlckVycm9yOwogfQogCkBAIC0xMTMzLDYgKzExNTgsNyBAQCBlX2NhbF9iYWNrZW5kX29nb19z dGFydF9xdWVyeSAoRUNhbEJhY2tlCiAJRUNhbEJhY2tlbmRPR29Qcml2YXRlICpwcml2OwogICAg ICAgICBHTGlzdCAqb2JqZWN0cyA9IE5VTEw7CiAKKwlmcHJpbnRmIChzdGRlcnIsIiVzXG4iLCAi ZV9jYWxfYmFja2VuZF9vZ29fc3RhcnRfcXVlcnkiKTsKIAlvZ28gPSBFX0NBTF9CQUNLRU5EX09H TyAoYmFja2VuZCk7CiAJcHJpdiA9IG9nby0+cHJpdjsKIApAQCAtMTIyNiw2ICsxMjUyLDExIEBA IGVfY2FsX2JhY2tlbmRfb2dvX2Rpc3Bvc2UgKEdPYmplY3QgKm9iamUKIAkJcHJpdi0+dXNlcm5h bWUgPSBOVUxMOwogCX0KIAkKKwlpZiAocHJpdi0+dXNlcl9lbWFpbCkgeworCQlnX2ZyZWUgKHBy aXYtPnBhc3N3b3JkKTsKKwkJcHJpdi0+cGFzc3dvcmQgPSBOVUxMOworCX0KKwogCWlmIChwcml2 LT5wYXNzd29yZCkgewogCQlnX2ZyZWUgKHByaXYtPnBhc3N3b3JkKTsKIAkJcHJpdi0+cGFzc3dv cmQgPSBOVUxMOwotLS0gL2hvbWUvc3NocmV5YXMvYmxlaC9ldm9sdXRpb24tZ3JvdXBkYXYtMC4y L3V0aWxzL29nby1jb25uZWN0aW9uLmgJMjAwNS0wMi0wNiAxMzo1Nzo1Ny4wMDAwMDAwMDAgKzA1 MzAKKysrIHV0aWxzL29nby1jb25uZWN0aW9uLmgJMjAwNi0wNy0yNSAyMDozNDowNS4wMDAwMDAw MDAgKzA1MzAKQEAgLTE0Miw2ICsxNDIsOCBAQCBnY2hhciAgICAgICAgICAgICAgKm9nb19jb25u ZWN0aW9uX2dldF9pCiAKIHZvaWQgICAgICAgICAgICAgICAgb2dvX2l0ZW1fbGlzdF9mcmVlICAg ICAgICAgIChHTGlzdCAqaXRlbXMpOwogICAgICAKK2NvbnN0IGNoYXIgICAgICAgICAgICAgICpl X29nb19jb25uZWN0aW9uX2dldF91c2VyX2VtYWlsIChPR29Db25uZWN0aW9uICpjbmMpOworICAg ICAKIEdfRU5EX0RFQ0xTCiAKICNlbmRpZgotLS0gL2hvbWUvc3NocmV5YXMvYmxlaC9ldm9sdXRp b24tZ3JvdXBkYXYtMC4yL3V0aWxzL29nby1jb25uZWN0aW9uLmMJMjAwNS0wMi0yNSAwODoxMjo0 OC4wMDAwMDAwMDAgKzA1MzAKKysrIHV0aWxzL29nby1jb25uZWN0aW9uLmMJMjAwNi0wNy0yNSAy MDo0OTozNS4wMDAwMDAwMDAgKzA1MzAKQEAgLTQ0LDYgKzQ0LDcgQEAgc3RydWN0IF9PR29Db25u ZWN0aW9uUHJpdmF0ZSB7CiAJU291cFNlc3Npb24gKnNvdXBfc2Vzc2lvbjsKIAogCWNoYXIgKnVy aTsKKwljaGFyICp1c2VyX2VtYWlsOyAvL3RvIGJlIGltcGxlbWVudGVkCiAJY2hhciAqdXNlcm5h bWU7CiAJY2hhciAqcGFzc3dvcmQ7CiB9OwpAQCAtMzU5LDYgKzM2MCwxNSBAQCBvZ29fY29ubmVj dGlvbl9mZXRjaF9pdGVtX2Fic29sdXRlIChPR29DCiAJaHR0cF9zdGF0dXMgPSBzb3VwX3Nlc3Np b25fc2VuZF9tZXNzYWdlIChjb25uLT5wcml2LT5zb3VwX3Nlc3Npb24sIG1lc3NhZ2UpOwogCiAJ aWYgKChzdGF0dXMgPSBnZXRfc3RhdHVzX2Zyb21faHR0cF9yZXNwb25zZSAoaHR0cF9zdGF0dXMp KSA9PSBPR09fQ09OTkVDVElPTl9TVEFUVVNfT0spIHsKKworICAgICAgICAvLyBqYW5vc2NoOiBy ZXNwb25zZS5sZW5ndGggc2VlbXMgdG8gYmUgd3JvbmcsIGxldHMgd3JpdGUgYSAnXDAnIGludG8g dGhlIHN0cmluZyB0byB0ZXJtaW5hdGUgaXQgYXQgdGhlIGNvcnJlY3QgcG9zaXRpb24KKyAgICAg ICAgY2hhciAqcyA9IHN0cnN0cihtZXNzYWdlLT5yZXNwb25zZS5ib2R5LCAiRU5EOlZDQUxFTkRB UiIpOworICAgICAgICBpZiAocyAhPSBOVUxMKSB7CisgICAgICAgICAgICBzWzArc3RybGVuKCJF TkQ6VkNBTEVOREFSIildID0gJ1wwJzsKKyAgICAgICAgfQorICAgICAgICBtZXNzYWdlLT5yZXNw b25zZS5sZW5ndGggPSBzdHJsZW4obWVzc2FnZS0+cmVzcG9uc2UuYm9keSk7CisKKwogCQkqaXRl bV9jb250ZW50cyA9IGdfc3RybmR1cCAobWVzc2FnZS0+cmVzcG9uc2UuYm9keSwgCiAJCQkJCSAg ICBtZXNzYWdlLT5yZXNwb25zZS5sZW5ndGgpOwogCX0gZWxzZSB7CkBAIC00MDQsNiArNDE0LDE2 IEBAIHBhcnNlX2xpc3RfcmVzcG9uc2UgKHhtbERvY1B0ciAgICAgZG9jLAogCQlpZiAodXJpX25v ZGUtPmNoaWxkcmVuLT5jb250ZW50KQogCQkJaXRlbS0+dXJpID0gZ19zdHJkdXAgKHVyaV9ub2Rl LT5jaGlsZHJlbi0+Y29udGVudCk7CiAJCQorCQkJCisgIAkJLy8gamFub3NjaDogY3JlYXRlIHpl cm8gZXRhZyBmcm9tIGhyZWYgKHdpbGwgYmUgb3ZlcndyaXR0ZW4gYnkgZ2V0ZXRhZywgaWYgZ2V0 ZXRhZyBpcyBhdmFpbGFibGUpCisJICAgIGNoYXIqIHNob3J0X2lkOworCSAgICBjaGFyIGV0YWdb MTAwXTsKKwkgICAgc2hvcnRfaWQgPSByaW5kZXgoaXRlbS0+dXJpLCAnLycpICsgMTsKKwkgICAg c3ByaW50ZihldGFnLCAiJXM6MCIsIHNob3J0X2lkKTsKKwkJaXRlbS0+ZXRhZyA9IGdfc3RyZHVw IChldGFnKTsKKworCisJCQogCQlwcm9wc3RhdCA9IGZpbmRfZmlyc3RfY2hpbGQgKHJlc3BvbnNl LCAicHJvcHN0YXQiKTsKIAkJcHJvcCA9IGZpbmRfZmlyc3RfY2hpbGQgKHByb3BzdGF0LCAicHJv cCIpOwogCkBAIC00MTIsOSArNDMyLDE0IEBAIHBhcnNlX2xpc3RfcmVzcG9uc2UgKHhtbERvY1B0 ciAgICAgZG9jLAogCQkvKiBOb3cgd2FsayB0aHJvdWdoIGFsbCBwcm9wZXJ0aWVzICovCiAJCWZv ciAodmFsdWUgPSBwcm9wLT5jaGlsZHJlbjsgdmFsdWUgIT0gTlVMTDsgdmFsdWUgPSB2YWx1ZS0+ bmV4dCkgewogCQkJaWYgKHN0cmNtcCAodmFsdWUtPm5hbWUsICJnZXRldGFnIikgPT0gMCkgewor CQkJICAgIC8vIGphbm9zY2g6IGlnbm9yZSBlbXB0eSBnZXRldGFnIGNvbnRlbnQKKwkJCSAgICBp ZiAoIHZhbHVlLT5jaGlsZHJlbiA9PSBOVUxMIHx8IHZhbHVlLT5jaGlsZHJlbi0+Y29udGVudCA9 PSBOVUxMIHx8IHN0cmxlbih2YWx1ZS0+Y2hpbGRyZW4tPmNvbnRlbnQpPT0wICkgeworICAgIAkJ CSAgICAvLyBpZ25vcmUKKwkJCSAgICB9IGVsc2UgewogCQkJCWl0ZW0tPmV0YWcgPSBnX3N0cmR1 cCAodmFsdWUtPmNoaWxkcmVuLT5jb250ZW50KTsKIAkJCX0KIAkJfQorCQl9CiAKIAkJdG1wID0g Z19saXN0X3ByZXBlbmQgKHRtcCwgaXRlbSk7CiAJfQpAQCAtNDQxLDYgKzQ2NiwxNCBAQCBvZ29f Y29ubmVjdGlvbl9saXN0X2l0ZW1zIChPR29Db25uZWN0aW9uCiAJaHR0cF9zdGF0dXMgPSBzb3Vw X3Nlc3Npb25fc2VuZF9tZXNzYWdlIChjb25uLT5wcml2LT5zb3VwX3Nlc3Npb24sIG1lc3NhZ2Up OwogCiAJaWYgKChzdGF0dXMgPSBnZXRfc3RhdHVzX2Zyb21faHR0cF9yZXNwb25zZSAoaHR0cF9z dGF0dXMpKSA9PSBPR09fQ09OTkVDVElPTl9TVEFUVVNfT0spIHsKKyAgICAgICAgLy8gamFub3Nj aDogcmVzcG9uc2UubGVuZ3RoIHNlZW1zIHRvIGJlIHdyb25nLCBsZXRzIHdyaXRlIGEgJ1wwJyBp bnRvIHRoZSBzdHJpbmcgdG8gdGVybWluYXRlIGl0IGF0IHRoZSBjb3JyZWN0IHBvc2l0aW9uCisg ICAgICAgIGNoYXIgKnMgPSBzdHJzdHIobWVzc2FnZS0+cmVzcG9uc2UuYm9keSwgIjwvRDptdWx0 aXN0YXR1cz4iKTsKKyAgICAgICAgaWYgKHMgIT0gTlVMTCkgeworICAgICAgICAgICAgc1swK3N0 cmxlbigiPC9EOm11bHRpc3RhdHVzPiIpXSA9ICdcMCc7CisgICAgICAgIH0KKyAgICAgICAgbWVz c2FnZS0+cmVzcG9uc2UubGVuZ3RoID0gc3RybGVuKG1lc3NhZ2UtPnJlc3BvbnNlLmJvZHkpOwor ICAgICAgICAKKwogCQl4bWxEb2NQdHIgZG9jOwogCiAJCWRvYyA9IHhtbFJlYWRNZW1vcnkgKG1l c3NhZ2UtPnJlc3BvbnNlLmJvZHksIG1lc3NhZ2UtPnJlc3BvbnNlLmxlbmd0aCwgCkBAIC0xMDI5 LDQgKzEwNjIsMTQgQEAgb2dvX2Nvbm5lY3Rpb25fZ2V0X2l0ZW1fdXJpIChPR29Db25uZWN0aQog CXJldHVybiByZWFsX3VyaTsKIH0KIAorY29uc3QgY2hhciogCitlX29nb19jb25uZWN0aW9uX2dl dF91c2VyX2VtYWlsIChPR29Db25uZWN0aW9uICpjbmMpCit7CisJZ19yZXR1cm5fdmFsX2lmX2Zh aWwgKGNuYyAhPSBOVUxMLCBOVUxMKTsKKwlnX3JldHVybl92YWxfaWZfZmFpbCAoT0dPX0lTX0NP Tk5FQ1RJT04oY25jKSwgTlVMTCk7CisJCisJLypOZWVkIHRvIGFzayB0aGUgc2VydmVyIGZvciB0 aGUgZW1haWwgaWQgb3Igc2hvdWxkIGNyZWF0ZSBpdCBpbiBzb21lIG90aGVyd2F5Ki8KKwkvKkZv ciBub3cgaXQgY2FuIGJlIE5VTEwqLworCXJldHVybiBOVUxMOwogICAgICAKK30K ------=_Part_59759_25428202.1154971710468-- From evolution@opengroupware.org Tue Aug 8 10:08:08 2006 From: evolution@opengroupware.org (Helge Hess) Date: Tue, 8 Aug 2006 11:08:08 +0200 Subject: [OGo-Evolution] Improving the Ogo connector In-Reply-To: <8f8004410608071028h6de810abv2b0d902b74767c6b@mail.gmail.com> References: <8f8004410608071028h6de810abv2b0d902b74767c6b@mail.gmail.com> Message-ID: <5615142D-1942-4E08-8F2E-E472E856A2F3@opengroupware.org> On Aug 7, 2006, at 19:28, Shreyas Srinivasan wrote: > My research showed that there was no way to create new addressbook > elements as it was not supported by groupdav interface, has there been > a change in status. Not sure what you mean by that, probably you refer to the OGo 1.0 ZideStore not having PUT support for vCards? So, yes, the OGo ZideStore server (1.5) _does_ support creation of contacts (person and company) using vCard/GroupDAV. This was sponsored by the Junta de Andalusia / Yaco. > Also i have a couple of doubts about the existing > e-book-backend-ogo code, so if the original developers could help me > out in explaining a little of the code(only a couple of questions), > i would > be grateful. I suppose you should just post your questions to this list. I'm not the original author but maybe I or someone else can help :-) > I have some experience in working with evolution as i used to maintain > the evolution mailer and the mac osx port when i was at Novell. Nice! > I am attaching a diff of the work i have done so far (diff'ed against > evolution head), its not much but i hope to do a lot more. > Hopefully if i can > understand the current connector code base well, i can work on > extending it to current opengroupware feature compatibility and also > work on some stability work. Looking forward to hearing from all of > you. I have no idea how good the codebase is from an Evolution 2.6 point of view. You can probably tell us? ;-) What Svn tree do you use as a basis? (My branch, or something from Robert?) Where should we put the source code tree, should we setup a new Svn repository at developer.opengroupware.org? Let us know what we can do to help you! Thanks a lot! Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From evolution@opengroupware.org Wed Aug 9 06:54:49 2006 From: evolution@opengroupware.org (Robert de Geus) Date: Wed, 09 Aug 2006 07:54:49 +0200 Subject: [OGo-Evolution] Improving the Ogo connector In-Reply-To: <5615142D-1942-4E08-8F2E-E472E856A2F3@opengroupware.org> References: <8f8004410608071028h6de810abv2b0d902b74767c6b@mail.gmail.com> <5615142D-1942-4E08-8F2E-E472E856A2F3@opengroupware.org> Message-ID: <1155102889.16926.7.camel@salsa-10-0-0-2> Hi Helge, Any help is great. As you might have guessed we have asked Shreyas to finish off the connector. It is a good idea to set up a svn repositry on download.opengroupware.org and give Shreyas access to it. He discovered that the contact part of the connector needs a lot of reworking, though reading works. We are now investigating an in between version where all calendar functionality works and Contacts and Task are in read only mode. This will be sufficient for most production environments to start with. After this he will work on tasks and contacts. gr. Robert From evolution@opengroupware.org Wed Aug 9 08:53:31 2006 From: evolution@opengroupware.org (Shreyas Srinivasan) Date: Wed, 09 Aug 2006 13:23:31 +0530 Subject: [OGo-Evolution] Improving the Ogo connector In-Reply-To: <5615142D-1942-4E08-8F2E-E472E856A2F3@opengroupware.org> References: <8f8004410608071028h6de810abv2b0d902b74767c6b@mail.gmail.com> <5615142D-1942-4E08-8F2E-E472E856A2F3@opengroupware.org> Message-ID: <1155110012.3339.23.camel@localhost.localdomain> --=-aiH4Qm1sfMQ0quqVSLr6 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2006-08-08 at 11:08 +0200, Helge Hess wrote: > On Aug 7, 2006, at 19:28, Shreyas Srinivasan wrote: > So, yes, the OGo ZideStore server (1.5) _does_ support creation of =20 > contacts (person and company) using vCard/GroupDAV. This was =20 > sponsored by the Junta de Andalusia / Yaco. Wonderful, is there a place where updated the Soap Schema is published. Also has the soap schema/api for modifying contacts changed, looks like the one used in the code returns a 405 from the server.=20 > I suppose you should just post your questions to this list. I'm not =20 > the original author but maybe I or someone else can help :-) Cool, i figured out a few of them myself but will post about a couple of grey areas to the list. > I have no idea how good the codebase is from an Evolution 2.6 point =20 > of view. You can probably tell us? ;-) Heh, it gets easier with time. I think right now, we are heading=20 towards complete functionality very fast. > What Svn tree do you use as a basis? (My branch, or something from =20 > Robert?) Where should we put the source code tree, should we setup a =20 > new Svn repository at developer.opengroupware.org? > Let us know what we can do to help you! I am using Robert's tar file, can we have a branch for me which i can=20 commit too, and we can release that after sufficient testing has been=20 done. What do you think? Do i send patches to this list? Or is there some other list for that? > Thanks a lot! Thanks for the support.=20 -- Shreyas --=-aiH4Qm1sfMQ0quqVSLr6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBE2ZR7Zbzqrm8h9vMRArVUAJ9L4DVHmRwK7uvHJ4Whc0qE17BH8gCaArW5 mVNe8Z/PTd6vL7bHfdO1H+E= =u4d7 -----END PGP SIGNATURE----- --=-aiH4Qm1sfMQ0quqVSLr6-- From evolution@opengroupware.org Wed Aug 9 09:22:08 2006 From: evolution@opengroupware.org (Helge Hess) Date: Wed, 9 Aug 2006 10:22:08 +0200 Subject: [OGo-Evolution] Improving the Ogo connector In-Reply-To: <1155102889.16926.7.camel@salsa-10-0-0-2> References: <8f8004410608071028h6de810abv2b0d902b74767c6b@mail.gmail.com> <5615142D-1942-4E08-8F2E-E472E856A2F3@opengroupware.org> <1155102889.16926.7.camel@salsa-10-0-0-2> Message-ID: <64AFAB39-5151-4D2E-8D5E-936F0D283F1A@opengroupware.org> On Aug 9, 2006, at 07:54, Robert de Geus wrote: > Any help is great. As you might have guessed we have asked Shreyas to > finish off the connector. Cool! > It is a good idea to set up a svn repositry on > download.opengroupware.org and give Shreyas access to it. I've setup this directory: http://developer.opengroupware.org/OGoProjects/evolution/trunk/ shreyas Shreyas can use it to work on his version of the connector (which we can make the primary one later on :-). This is automatically mirrored to the read-only Svn: http://svn.opengroupware.org/OGoProjects/evolution/trunk/shreyas > He discovered that the contact part of the connector needs a lot of > reworking, though reading works. Ok. > We are now investigating an in between > version where all calendar functionality works and Contacts and > Task are > in read only mode. Note that we still have no task-PUT in ZideStore. > This will be sufficient for most production > environments to start with. After this he will work on tasks and > contacts. Well, if its just calendar, it would make more sense to tweak the Evolution CalDAV connector? Though I have no idea how well developed that is. But probably makes more sense to use a single connector for CalDAV and GroupDAV. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From evolution@opengroupware.org Wed Aug 9 09:24:49 2006 From: evolution@opengroupware.org (Helge Hess) Date: Wed, 9 Aug 2006 10:24:49 +0200 Subject: [OGo-Evolution] Improving the Ogo connector In-Reply-To: <1155110012.3339.23.camel@localhost.localdomain> References: <8f8004410608071028h6de810abv2b0d902b74767c6b@mail.gmail.com> <5615142D-1942-4E08-8F2E-E472E856A2F3@opengroupware.org> <1155110012.3339.23.camel@localhost.localdomain> Message-ID: <6B40D240-A86F-405E-893C-C6EC955CF8CA@opengroupware.org> On Aug 9, 2006, at 09:53, Shreyas Srinivasan wrote: > Wonderful, is there a place where updated the Soap Schema is > published. Also has the soap schema/api for modifying contacts > changed, > looks like the one used in the code returns a 405 from the server. SOAP? We do GroupDAV: http://www.groupdav.org/ > Heh, it gets easier with time. I think right now, we are heading > towards complete functionality very fast. Very nice. > I am using Robert's tar file, can we have a branch for me which i can > commit too, and we can release that after sufficient testing has been > done. What do you think? Sounds great. You can use the Subversion URL I posted as a working space. > Do i send patches to this list? Or is there some other list for that? Just commit your stuff to the Svn. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From evolution@opengroupware.org Mon Aug 7 19:07:14 2006 From: evolution@opengroupware.org (Robert de Geus) Date: Mon, 07 Aug 2006 20:07:14 +0200 Subject: [OGo-Evolution] Improving the Ogo connector In-Reply-To: <8f8004410608071028h6de810abv2b0d902b74767c6b@mail.gmail.com> References: <8f8004410608071028h6de810abv2b0d902b74767c6b@mail.gmail.com> Message-ID: <1154974034.14791.2.camel@salsa-client> Hi, Is Alvaro still around? I think he is the one who can explain the current code. My guess is Helge can help with the zidestore part. It would be very helpfull if we can give Shreyas the information he needs, gr. Robert On Mon, 2006-08-07 at 22:58 +0530, Shreyas Srinivasan wrote: > Hey, > > I am looking at porting and improving the ogo connector to work with evolution > 2.[6,8]. I have been working on it for about a week now and have made > a little progress. Calendar elements creation, edition and deletion works > smoothly (it used to work i am told, i just fixed a couple of bugs). Now > i am looking at fixing addressbook and tasks. > > My research showed that there was no way to create new addressbook > elements as it was not supported by groupdav interface, has there been > a change in status. Also i have a couple of doubts about the existing > e-book-backend-ogo code, so if the original developers could help me > out in explaining a little of the code(only a couple of questions), i would > be grateful. > > I have some experience in working with evolution as i used to maintain > the evolution mailer and the mac osx port when i was at Novell. > > I am attaching a diff of the work i have done so far (diff'ed against > evolution head), its not much but i hope to do a lot more. Hopefully if i can > understand the current connector code base well, i can work on > extending it to current opengroupware feature compatibility and also > work on some stability work. Looking forward to hearing from all of > you. > > Thanks, > Shreyas From evolution@opengroupware.org Fri Aug 11 13:35:53 2006 From: evolution@opengroupware.org (Helge Hess) Date: Fri, 11 Aug 2006 14:35:53 +0200 Subject: [OGo-Evolution] Improving the Ogo connector In-Reply-To: <1154974034.14791.2.camel@salsa-client> References: <8f8004410608071028h6de810abv2b0d902b74767c6b@mail.gmail.com> <1154974034.14791.2.camel@salsa-client> Message-ID: <884B2F28-D72C-451E-83D8-41150B350B66@opengroupware.org> On Aug 7, 2006, at 20:07, Robert de Geus wrote: > Is Alvaro still around? I think he is the one who can explain the > current code. I don't think Alvaro still knows about the code, AFAIK he doesn't do a lot of GNOME development nowadays. He's probably still subscribed to the Noodle list though. Just ask your questions and we'll see whether we can answer them :-) > My guess is Helge can help with the zidestore part. > > It would be very helpfull if we can give Shreyas the information he > needs, Hm, yes. So far there are no open requests for information? :-) Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From evolution@opengroupware.org Fri Aug 11 13:54:40 2006 From: evolution@opengroupware.org (Toltech Solutions BV) Date: Fri, 11 Aug 2006 14:54:40 +0200 Subject: [OGo-Evolution] Improving the Ogo connector In-Reply-To: <884B2F28-D72C-451E-83D8-41150B350B66@opengroupware.org> References: <8f8004410608071028h6de810abv2b0d902b74767c6b@mail.gmail.com> <1154974034.14791.2.camel@salsa-client> <884B2F28-D72C-451E-83D8-41150B350B66@opengroupware.org> Message-ID: <1155300880.6934.51.camel@salsa-10-1-0-16> --=-hGDeRKER8LI/VEA3M0B9 Content-Type: text/plain Content-Transfer-Encoding: 7bit Alvaro has another email address, perhaps we can email him acs@andago.com grts JP On Fri, 2006-08-11 at 14:35 +0200, Helge Hess wrote: > On Aug 7, 2006, at 20:07, Robert de Geus wrote: > > Is Alvaro still around? I think he is the one who can explain the > > current code. > > I don't think Alvaro still knows about the code, AFAIK he doesn't do > a lot of GNOME development nowadays. > He's probably still subscribed to the Noodle list though. > > Just ask your questions and we'll see whether we can answer them :-) > > > My guess is Helge can help with the zidestore part. > > > > It would be very helpfull if we can give Shreyas the information he > > needs, > > Hm, yes. So far there are no open requests for information? :-) > > Greets, > Helge > -- > Helge Hess > http://docs.opengroupware.org/Members/helge/ > > --=-hGDeRKER8LI/VEA3M0B9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Alvaro has another email address, perhaps we can email him

acs@andago.com

grts
JP


On Fri, 2006-08-11 at 14:35 +0200, Helge Hess wrote: 
On Aug 7, 2006, at 20:07, Robert de Geus wrote:
> Is Alvaro still around? I think he is the one who can explain the
> current code.

I don't think Alvaro still knows about the code, AFAIK he doesn't do  
a lot of GNOME development nowadays.
He's probably still subscribed to the Noodle list though.

Just ask your questions and we'll see whether we can answer them :-)

> My guess is Helge can help with the zidestore part.
>
> It would be very helpfull if we can give Shreyas the information he
> needs,

Hm, yes. So far there are no open requests for information? :-)

Greets,
   Helge
-- 
Helge Hess
http://docs.opengroupware.org/Members/helge/
--=-hGDeRKER8LI/VEA3M0B9-- From evolution@opengroupware.org Wed Aug 16 09:44:39 2006 From: evolution@opengroupware.org (Helge Hess) Date: Wed, 16 Aug 2006 10:44:39 +0200 Subject: [OGo-Evolution] Re: Client understanding of timezones In-Reply-To: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> Message-ID: Hi Shreyas, please send mail to the mailing list. Other may want to know and may be able to answers, thanks. On Aug 16, 2006, at 10:11, Shreyas Srinivasan wrote: > So i am trying to understand how the client should handle the various > timezone based issues. > > This is my current understanding, > > The client sends utc, server maintains and returns utc and the client > uses the timezone info it has to set the correct time right ? Yes, this is how its done in OGo. A server can also choose to store in other timezones, but we recommend using UTC whenever its possible for optimal interoperability. This is not possible for calculated recurrences [because it needs to consider DST shifts], but this is not an immediate concern. Summary: - OGo will always send you UTC (, currently) - other servers (eg Scalable OGo) may send you other timezones - yes, the client should adjust to the timezone configured by the user for display (I suppose the adjust should be done somewhere in the display layer, not in the storage of Evolution?) - it is recommended that the client sends UTC to the server (Z suffix timevalues) except for cyclic events > Also is there more information about teams in calendars Well, two things to say about this one: a) teams are mapped to folders b) teams are mapped to contacts a) That is, to access a calendar of "Dev Team", you would select the /zidestore/dav/helge/Groups/Dev Team/Calendar Calendar in Evolution. The "Dev Team" is mapped to the read-access- group configured in the appointment. b) To make appointments _with_ teams (invite a whole team to an event), teams are also exposed as regular contacts. They live as VCF files in the /zidestore/dav/user/Groups GroupDAV collection. [ c) All team members also live as VCF records below the /zidestore/dav/ user/Groups/team/ collection. ] > and categories in contacts. The CATEGORIES vCard field is mapped to the 'keywords' OGo field. I think there are no specific things to be said about it, its something which maps 1:1. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From evolution@opengroupware.org Wed Aug 16 17:17:18 2006 From: evolution@opengroupware.org (Robert de Geus) Date: Wed, 16 Aug 2006 18:17:18 +0200 Subject: [OGo-Evolution] Re: Client understanding of timezones In-Reply-To: References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> Message-ID: <1155745038.15062.10.camel@salsa-10-1-0-237> Hi Helge, Looking at the bugzilla.opengroupware.org, there is an evolution-connector bug component. Would it be possible for me to become a moderator of only that part? This way Shreyas and I can enter bugs in the bugzilla, make it available to everyone, but have me to check bugs out, order and prioritize them? An alternative would be that we set up a trac ourselves, but that would disperse the information again. gr. Robert From evolution@opengroupware.org Wed Aug 16 18:25:12 2006 From: evolution@opengroupware.org (Helge Hess) Date: Wed, 16 Aug 2006 19:25:12 +0200 Subject: [OGo-Evolution] Re: Client understanding of timezones In-Reply-To: <1155745038.15062.10.camel@salsa-10-1-0-237> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <1155745038.15062.10.camel@salsa-10-1-0-237> Message-ID: <18EEBF39-64FD-4B73-959E-57F7BA842E09@opengroupware.org> On Aug 16, 2006, at 18:17, Robert de Geus wrote: > Looking at the bugzilla.opengroupware.org, there is an > evolution-connector bug component. Would it be possible for me to > become > a moderator of only that part? > > This way Shreyas and I can enter bugs in the bugzilla, make it > available > to everyone, but have me to check bugs out, order and prioritize them? Sure, no problem. I'll have a look. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From evolution@opengroupware.org Wed Aug 16 20:40:22 2006 From: evolution@opengroupware.org (Shreyas Srinivasan) Date: Thu, 17 Aug 2006 01:10:22 +0530 Subject: [OGo-Evolution] Re: Client understanding of timezones In-Reply-To: References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> Message-ID: <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> ------=_Part_1178_4618708.1155757222269 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hey, When i try to create a event (appointment/meeting) with an alarm. The server seems to lose it the first time, when i edit the same component the server returns the alarm (TRIGGER). Any clue whats wrong? The groupdav spews look like this. This PUT /zidestore/dav/ssers/public/Calendar/new.ics HTTP/1.1 [snip] BEGIN:VCALENDAR BEGIN:VEVENT [snip] SUMMARY:errrr dude LOCATION:errrr dude DESCRIPTION:why doesnt trigger work? [snip] BEGIN:VALARM DESCRIPTION:errrr dude ACTION:DISPLAY TRIGGER;VALUE=DURATION;RELATED=START:-PT15M END:VALARM END:VEVENT END:VCALENDAR In response the server on update returns: BEGIN:VCALENDAR METHOD:REQUEST [snip] DESCRIPTION:why doesnt trigger work? DTEND:20060817T050000Z DTSTART:20060817T043000Z [snip] TRANSP:OPAQUE UID:skyrix://s0040f45f2f51/s0011d8e0b699-ogo/43110 CREATED:20030710T120000Z DTSTAMP:20060816T161604Z Name":MAILTO:shreyas@gmail.com ORGANIZER;CN="No Name":MAILTO:shreyas@gmail.com END:VEVENT END:VCALENDAR Clearly the TRIGGER is not returned by the server. Am i doing something wrong or is it a server bug. I am attaching traces of the modify component which works as i expected. ps: Create-Trigger: Traces of creating a new event and the server response on update Modify-Trigger: Traces of Modifying an Element and Server Response on update Also i just committed my current working directory to svn. Also wrote up a Changelog on the work i have done so far. Please have a look and let me know if i have done anything wrong. Thanks for all help. -- Shreyas ------=_Part_1178_4618708.1155757222269 Content-Type: application/octet-stream; name=modify-trigger Content-Transfer-Encoding: base64 X-Attachment-Id: f_eqy3xxi8 Content-Disposition: attachment; filename="modify-trigger" UFVUIC96aWRlc3RvcmUvZGF2L3NzaHJleWFzL3B1YmxpYy9DYWxlbmRhci80MzExMC5pY3MgSFRU UC8xLjEKU09BUC1EZWJ1ZzogMHhhNGQwZjAgQCAxMTU1NzQ0NjE5Ckhvc3Q6IHd3dy5zYWxzYXRl Y2hub2xvZ3kuY29tCklmLW1hdGNoOiA0MzExMDoxCkNvbnRlbnQtVHlwZTogdGV4dC9jYWxlbmRh cgoKQkVHSU46VkNBTEVOREFSCkJFR0lOOlZFVkVOVApDTEFTUzpQUklWQVRFCkxPQ0FUSU9OOmVy cnJyIGR1ZGUKU1RBVFVTOkNPTkZJUk1FRApTVU1NQVJZOmVycnJyIGR1ZGUKRFRFTkQ6MjAwNjA4 MTdUMDUwMDAwWgpEVFNUQVJUOjIwMDYwODE3VDA0MzAwMFoKVFJBTlNQOk9QQVFVRQpVSUQ6c2t5 cml4Oi8vczAwNDBmNDVmMmY1MS9zMDAxMWQ4ZTBiNjk5LW9nby80MzExMApDUkVBVEVEOjIwMDMw NzEwVDEyMDAwMFoKRFRTVEFNUDoyMDA2MDgxNlQxNjE2MDRaClgtTUlDUk9TT0ZULUNETy1JTVBP UlRBTkNFOjAKWC1NSUNST1NPRlQtQ0RPLUJVU1lTVEFUVVM6QlVTWQpYLU1JQ1JPU09GVC1DRE8t SU5TVFRZUEU6MApYLU1JQ1JPU09GVC1DRE8tQUxMREFZRVZFTlQ6RkFMU0UKT1JHQU5JWkVSO0NO PU5vIE5hbWU6TUFJTFRPOnNocmV5YXNAZ21haWwuY29tClgtT0dPLUVUQUc6NDMxMTA6MQpYLU9H Ty1IUkVGOmh0dHA6CiAvLzEyNy4wLjAuMS96aWRlc3RvcmUvZGF2L3NzaHJleWFzL3B1YmxpYy9D YWxlbmRhci80MzExMC5pY3MKREVTQ1JJUFRJT046d2h5IGRvZXNudCB0cmlnZ2VyIHdvcms/CkFU VEVOREVFO0NVVFlQRT1JTkRJVklEVUFMO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5F RURTLUFDVElPTjsKIFJTVlA9RkFMU0U7Q049Tm8gTmFtZTpNQUlMVE86c2hyZXlhc0BnbWFpbC5j b20KQkVHSU46VkFMQVJNClgtRVZPTFVUSU9OLUFMQVJNLVVJRDoyMDA2MDgxNlQxNjEwMTlaLTEw NTExLTEwLTI4OTAtMzFAd3RmYwpERVNDUklQVElPTjplcnJyciBkdWRlCkFDVElPTjpESVNQTEFZ ClRSSUdHRVI7VkFMVUU9RFVSQVRJT047UkVMQVRFRD1TVEFSVDotUFQxNU0KRU5EOlZBTEFSTQpF TkQ6VkVWRU5UCkVORDpWQ0FMRU5EQVIKCjIwMCBPSwpTT0FQLURlYnVnOiAweGE0ZDBmMCBAIDEx NTU3NDQ2MjAKZXRhZzogNDMxMTA6MgpEYXRlOiBXZWQsIDE2IEF1ZyAyMDA2IDE2OjE4OjIwIEdN VApTZXJ2ZXI6IEFwYWNoZS8yLjAuNTUgKERlYmlhbikgUEhQLzUuMS4yLTErYjEKY29udGVudC1s ZW5ndGg6IDAKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluClRoZSBTZXJ2ZXIgcmV0dXJuZWQ6QkVH SU46VkNBTEVOREFSCk1FVEhPRDpSRVFVRVNUClBST0RJRDotLy9PcGVuR3JvdXB3YXJlLm9yZy9a aWRlU3RvcmUgMS4zLy8KVkVSU0lPTjoyLjAKQkVHSU46VkVWRU5UCkNMQVNTOlBSSVZBVEUKTE9D QVRJT046ZXJycnIgZHVkZQpTVEFUVVM6Q09ORklSTUVEClNVTU1BUlk6ZXJycnIgZHVkZQpERVND UklQVElPTjp3aHkgZG9lc250IHRyaWdnZXIgd29yaz8KRFRFTkQ6MjAwNjA4MTdUMDUwMDAwWgpE VFNUQVJUOjIwMDYwODE3VDA0MzAwMFoKVFJBTlNQOk9QQVFVRQpVSUQ6c2t5cml4Oi8vczAwNDBm NDVmMmY1MS9zMDAxMWQ4ZTBiNjk5LW9nby80MzExMApDUkVBVEVEOjIwMDMwNzEwVDEyMDAwMFoK TEFTVC1NT0RJRklFRDoyMDA2MDgxNlQxNjE4MjBaCkRUU1RBTVA6MjAwNjA4MTZUMTYxODIyWgpY LU1JQ1JPU09GVC1DRE8tSU1QT1JUQU5DRTowClgtTUlDUk9TT0ZULUNETy1CVVNZU1RBVFVTOkJV U1kKWC1NSUNST1NPRlQtQ0RPLUlOU1RUWVBFOjAKWC1NSUNST1NPRlQtQ0RPLUFMTERBWUVWRU5U OkZBTFNFCkJFR0lOOlZBTEFSTQpBQ1RJT046RElTUExBWQpERVNDUklQVElPTjplcnJyciBkdWRl ClRSSUdHRVI7VkFMVUU9RFVSQVRJT047UkVMQVRFRD1TVEFSVDotUFQxNU0KRU5EOlZBTEFSTQpB VFRFTkRFRTtDVVRZUEU9IklORElWSURVQUwiO1BBUlRTVEFUPSJORUVEUy1BQ1RJT04iO1JPTEU9 IlJFUS1QQVJUSUNJUEFOVCI7UlNWUD0iRkFMU0UiO0NOPSJObyBOYW1lIjpNQUlMVE86c2hyZXlh c0BnbWFpbC5jb20KRU5EOlZFVkVOVApFTkQ6VkNBTEVOREFSCg== ------=_Part_1178_4618708.1155757222269 Content-Type: application/octet-stream; name=create-trigger Content-Transfer-Encoding: base64 X-Attachment-Id: f_eqy3yba4 Content-Disposition: attachment; filename="create-trigger" UFVUIC96aWRlc3RvcmUvZGF2L3NzaHJleWFzL3B1YmxpYy9DYWxlbmRhci9uZXcuaWNzIEhUVFAv MS4xClNPQVAtRGVidWc6IDB4NWZiNmYwIEAgMTE1NTc0NDQ4MQpIb3N0OiB3d3cuc2Fsc2F0ZWNo bm9sb2d5LmNvbQpJZi1tYXRjaDogKgpDb250ZW50LVR5cGU6IHRleHQvY2FsZW5kYXIKCkJFR0lO OlZDQUxFTkRBUgpCRUdJTjpWRVZFTlQKVUlEOjIwMDYwODE2VDE2MDczOFotMTA1MDktMTAtMjgw Ny00QHd0ZmMKRFRTVEFNUDoyMDA2MDgxNlQxNjA3MzhaCkRUU1RBUlQ6MjAwNjA4MTdUMDQzMDAw WgpEVEVORDoyMDA2MDgxN1QwNTAwMDBaClRSQU5TUDpPUEFRVUUKU0VRVUVOQ0U6MgpTVU1NQVJZ OmVycnJyIGR1ZGUKTE9DQVRJT046ZXJycnIgZHVkZQpERVNDUklQVElPTjp3aHkgZG9lc250IHRy aWdnZXIgd29yaz8KQ0xBU1M6UFJJVkFURQpCRUdJTjpWQUxBUk0KWC1FVk9MVVRJT04tQUxBUk0t VUlEOjIwMDYwODE2VDE2MDgwMVotMTA1MTEtMTAtMjg5MC0yNUB3dGZjCkRFU0NSSVBUSU9OOmVy cnJyIGR1ZGUKQUNUSU9OOkRJU1BMQVkKVFJJR0dFUjtWQUxVRT1EVVJBVElPTjtSRUxBVEVEPVNU QVJUOi1QVDE1TQpFTkQ6VkFMQVJNCkVORDpWRVZFTlQKRU5EOlZDQUxFTkRBUgoKMjAwIE9LClNP QVAtRGVidWc6IDB4NWZiNmYwIEAgMTE1NTc0NDQ4MgpldGFnOiA0MzExMDoxCkRhdGU6IFdlZCwg MTYgQXVnIDIwMDYgMTY6MTY6MDEgR01UCmxvY2F0aW9uOiBodHRwOi8vMTI3LjAuMC4xL3ppZGVz dG9yZS9kYXYvc3NocmV5YXMvcHVibGljL0NhbGVuZGFyLzQzMTEwLmljcwpTZXJ2ZXI6IEFwYWNo ZS8yLjAuNTUgKERlYmlhbikgUEhQLzUuMS4yLTErYjEKY29udGVudC1sZW5ndGg6IDAKQ29udGVu dC1UeXBlOiB0ZXh0L3BsYWluClRoZSBTZXJ2ZXIgcmV0dXJuZWQ6QkVHSU46VkNBTEVOREFSCk1F VEhPRDpSRVFVRVNUClBST0RJRDotLy9PcGVuR3JvdXB3YXJlLm9yZy9aaWRlU3RvcmUgMS4zLy8K VkVSU0lPTjoyLjAKQkVHSU46VkVWRU5UCkNMQVNTOlBSSVZBVEUKTE9DQVRJT046ZXJycnIgZHVk ZQpTVEFUVVM6Q09ORklSTUVEClNVTU1BUlk6ZXJycnIgZHVkZQpERVNDUklQVElPTjp3aHkgZG9l c250IHRyaWdnZXIgd29yaz8KRFRFTkQ6MjAwNjA4MTdUMDUwMDAwWgpEVFNUQVJUOjIwMDYwODE3 VDA0MzAwMFoKVFJBTlNQOk9QQVFVRQpVSUQ6c2t5cml4Oi8vczAwNDBmNDVmMmY1MS9zMDAxMWQ4 ZTBiNjk5LW9nby80MzExMApDUkVBVEVEOjIwMDMwNzEwVDEyMDAwMFoKRFRTVEFNUDoyMDA2MDgx NlQxNjE2MDRaClgtTUlDUk9TT0ZULUNETy1JTVBPUlRBTkNFOjAKWC1NSUNST1NPRlQtQ0RPLUJV U1lTVEFUVVM6QlVTWQpYLU1JQ1JPU09GVC1DRE8tSU5TVFRZUEU6MApYLU1JQ1JPU09GVC1DRE8t QUxMREFZRVZFTlQ6RkFMU0UKQVRURU5ERUU7Q1VUWVBFPSJJTkRJVklEVUFMIjtQQVJUU1RBVD0i TkVFRFMtQUNUSU9OIjtST0xFPSJSRVEtUEFSVElDSVBBTlQiO1JTVlA9IkZBTFNFIjtDTj0iTm8g TmFtZSI6TUFJTFRPOnNocmV5YXNAZ21haWwuY29tCk9SR0FOSVpFUjtDTj0iTm8gTmFtZSI6TUFJ TFRPOnNocmV5YXNAZ21haWwuY29tCkVORDpWRVZFTlQKRU5EOlZDQUxFTkRBUgoKCg== ------=_Part_1178_4618708.1155757222269-- From evolution@opengroupware.org Wed Aug 16 21:12:40 2006 From: evolution@opengroupware.org (Helge Hess) Date: Wed, 16 Aug 2006 22:12:40 +0200 Subject: [OGo-Evolution] Re: Client understanding of timezones In-Reply-To: <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> Message-ID: <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> On Aug 16, 2006, at 21:40, Shreyas Srinivasan wrote: > When i try to create a event (appointment/meeting) with an alarm. > The server seems to lose it the first time, when i edit the same > component the server returns the alarm (TRIGGER). Possibly a bug in ZideStore. You might want to file a bugreport, ideally with a small testcase. > Any clue whats wrong? The groupdav spews look like this. Well, OGo can't store everything in iCalendar, but it should store most stuff used by Evolution. A list what does and doesn't work would be nice. > This > > PUT /zidestore/dav/ssers/public/Calendar/new.ics HTTP/1.1 ... > In response the server on update returns: In response to the PUT or to a subsequent GET? > Clearly the TRIGGER is not returned by the server. Am i doing > something > wrong or is it a server bug. Possibly the latter. > Also i just committed my current working directory to svn. Also wrote > up a Changelog on the work i have done so far. Please have a look > and let me know if i have done anything wrong. Looks good. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From evolution@opengroupware.org Wed Aug 16 21:25:19 2006 From: evolution@opengroupware.org (Robert de Geus) Date: Wed, 16 Aug 2006 22:25:19 +0200 Subject: [OGo-Evolution] Re: Client understanding of timezones In-Reply-To: <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> Message-ID: <1155759919.29859.0.camel@salsa-10-0-0-2> Hi Shreyas, I am currently testing the bugzilla. Have you already become a member there? gr. Robert On Thu, 2006-08-17 at 01:10 +0530, Shreyas Srinivasan wrote: > Hey, > > When i try to create a event (appointment/meeting) with an alarm. > The server seems to lose it the first time, when i edit the same > component the server returns the alarm (TRIGGER). > > Any clue whats wrong? The groupdav spews look like this. > > This > > PUT /zidestore/dav/ssers/public/Calendar/new.ics HTTP/1.1 > [snip] > BEGIN:VCALENDAR > BEGIN:VEVENT > [snip] > SUMMARY:errrr dude > LOCATION:errrr dude > DESCRIPTION:why doesnt trigger work? > [snip] > BEGIN:VALARM > DESCRIPTION:errrr dude > ACTION:DISPLAY > TRIGGER;VALUE=DURATION;RELATED=START:-PT15M > END:VALARM > END:VEVENT > END:VCALENDAR > > In response the server on update returns: > > BEGIN:VCALENDAR > METHOD:REQUEST > [snip] > DESCRIPTION:why doesnt trigger work? > DTEND:20060817T050000Z > DTSTART:20060817T043000Z > [snip] > TRANSP:OPAQUE > UID:skyrix://s0040f45f2f51/s0011d8e0b699-ogo/43110 > CREATED:20030710T120000Z > DTSTAMP:20060816T161604Z > Name":MAILTO:shreyas@gmail.com > ORGANIZER;CN="No Name":MAILTO:shreyas@gmail.com > END:VEVENT > END:VCALENDAR > > Clearly the TRIGGER is not returned by the server. Am i doing something > wrong or is it a server bug. I am attaching traces of the modify component > which works as i expected. > > ps: Create-Trigger: Traces of creating a new event and the server > response on update > Modify-Trigger: Traces of Modifying an Element and Server Response on update > > Also i just committed my current working directory to svn. Also wrote > up a Changelog > on the work i have done so far. Please have a look and let me know if i have > done anything wrong. > > Thanks for all help. > > -- > Shreyas > > > !DSPAM:44e3751d169451420723618! From evolution@opengroupware.org Wed Aug 16 21:51:40 2006 From: evolution@opengroupware.org (Robert de Geus) Date: Wed, 16 Aug 2006 22:51:40 +0200 Subject: [OGo-Evolution] OGo - evolution connector uploaded in CVS In-Reply-To: <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> Message-ID: <1155761500.29859.19.camel@salsa-10-0-0-2> Hi, We have uploaded the latest version in http://svn.opengroupware.org/OGoProjects/evolution/trunk/shreyas/ >From now on Shreyas will upload new versions when we have them. Lots of problems have been fixed and the connector is actually working quite well. We are focussing on the calendar, insert modify and delete work. The Contacts implementation in this version is in a bad shape. It appears it is not a pure groupdav implementation and it is not implementing caching like you would expect it too. We suggest not testing it with too many contacts. We are focusing on an "in" between version to get a good working central calendar in evolution using opengroupware. This version could already be used in certain situations. The next stage will be creating a fully functional version. We would like to invite everybody to download and test this version. We would also like to invite everyone to create bugs in the opengroupware bugzilla http://bugzilla.opengroupware.org The bugs can be filed under zidestore/Trunc/Evolution connector. I will order and check and assign the bugs. regards, Robert de Geus From evolution@opengroupware.org Wed Aug 16 23:35:02 2006 From: evolution@opengroupware.org (Helge Hess) Date: Thu, 17 Aug 2006 00:35:02 +0200 Subject: [OGo-Evolution] OGo - evolution connector uploaded in CVS In-Reply-To: <1155761500.29859.19.camel@salsa-10-0-0-2> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> <1155761500.29859.19.camel@salsa-10-0-0-2> Message-ID: <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> BTW: what kind of development environment do you use/recommend? Is Sarge a viable base to try the connector or is it w/o hope? ;-) I would like to avoid to install Evo/GNOME from source to try the connector. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From evolution@opengroupware.org Thu Aug 17 07:33:09 2006 From: evolution@opengroupware.org (Robert de Geus) Date: Thu, 17 Aug 2006 08:33:09 +0200 Subject: [OGo-Evolution] OGo - evolution connector uploaded in CVS In-Reply-To: <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> <1155761500.29859.19.camel@salsa-10-0-0-2> <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> Message-ID: <1155796389.32466.21.camel@salsa-10-0-0-2> Hi Helge, We are developing on Ubuntu dapper, I even think that Shreyas has even advanced a bit. At this moment we are testing for evolution 2.6.1. For those who are not very used to Ubuntu this is the cookbook we use to compile the connector: As root: apt-get update install dev packages: apt-get install evolution-dev evolution-data-server-dev in some directory, get the sources of evolution. This step is only needed to download all dependencies, the sources know what you need to compile evolution and will tell you what to download: apt-get source evolution apt-get source evolution-data-server To get all dependencies, cd in the evolution subtree dpkg-buildpackage (it will complain about missing packages) install packages with: apt-get install package-name repeat this step until evolution starts compiling. You don't need to finish this. Do the same with evolution-data-server Dapper has a lib dependency for evolution-plugin installed with version 2.6, the current connector looks for the 2.8 version. This can be solved by creating a symlink in: /usr/lib/pkgconfig/evolution-plugin-2.8.pc -> evolution-plugin-2.6.pc Test if make can find the lib: pkg-config --libs evolution-plugin-2.8 You now should be able to compile the connector. Download the sources and run the following: ./configure --prefix=/usr make make install as a normal user: evolution --force-shutdown evolution In preferences, ad an new account and select opengroupware.org as a driver. As a destination server enter the server name, you don't need to enter complicated links here. Zidestore should run of course. We test on one of the newest zidestore 1.5 versions. gr. Robert On Thu, 2006-08-17 at 00:35 +0200, Helge Hess wrote: > BTW: what kind of development environment do you use/recommend? > > Is Sarge a viable base to try the connector or is it w/o hope? ;-) > > I would like to avoid to install Evo/GNOME from source to try the > connector. > > Greets, > Helge > -- > Helge Hess > http://docs.opengroupware.org/Members/helge/ > > From evolution@opengroupware.org Thu Aug 17 07:46:29 2006 From: evolution@opengroupware.org (Robert de Geus) Date: Thu, 17 Aug 2006 08:46:29 +0200 Subject: [OGo-Evolution] Groupdav website update In-Reply-To: <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> <1155761500.29859.19.camel@salsa-10-0-0-2> <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> Message-ID: <1155797189.32466.32.camel@salsa-10-0-0-2> Hi Helge, Is it possible to update the groupdav.org site? We could update the links (to the cvs) and name the new people? It would be nice if we also keep the old references and names. We might also make a page with the cookbook I wrote in a previous mail, so everyone can compile the connector easily. Shreyas Srinivasan Christo Buschec crito@toltech.nl Robert de Geus robert@toltech.nl JP van der Kuijl jp@toltech.nl The project is now sponsored by: Toltech Solutions B.V. Jacob van Lennepkade 151 1054 ZL Amsterdam Phone +31 (0)20 6185618 Email sales@toltech.nl http://www.salsatechnologies.eu (we will install a website today) gr. Robert From evolution@opengroupware.org Thu Aug 17 10:21:41 2006 From: evolution@opengroupware.org (Helge Hess) Date: Thu, 17 Aug 2006 11:21:41 +0200 Subject: [OGo-Evolution] Groupdav website update In-Reply-To: <1155797189.32466.32.camel@salsa-10-0-0-2> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> <1155761500.29859.19.camel@salsa-10-0-0-2> <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> <1155797189.32466.32.camel@salsa-10-0-0-2> Message-ID: On Aug 17, 2006, at 08:46, Robert de Geus wrote: > Is it possible to update the groupdav.org site? We could update the > links (to the cvs) and name the new people? It would be nice if we > also > keep the old references and names. We might also make a page with the > cookbook I wrote in a previous mail, so everyone can compile the > connector easily. Sure, I can give you write access to the website. You won't be able to update it directly (uses a weird and deprecated CMS), but you can change the content in Svn. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From evolution@opengroupware.org Thu Aug 17 10:43:31 2006 From: evolution@opengroupware.org (Helge Hess) Date: Thu, 17 Aug 2006 11:43:31 +0200 Subject: [OGo-Evolution] OGo - evolution connector uploaded in CVS In-Reply-To: <1155796389.32466.21.camel@salsa-10-0-0-2> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> <1155761500.29859.19.camel@salsa-10-0-0-2> <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> <1155796389.32466.21.camel@salsa-10-0-0-2> Message-ID: <1E802981-108B-4DDF-8FEA-BC3C5E2A87F2@opengroupware.org> On Aug 17, 2006, at 08:33, Robert de Geus wrote: > Dapper has a lib dependency for evolution-plugin installed with > version > 2.6, the current connector looks for the 2.8 version. Could you elaborate? Is 2.6 and 2.8 API compatible? Will the connector work for both? How different is the 2.4 and 2.6 API? Is it viable to produce a 2.4 variant? Would be good if we could produce a connector which does not only work against the bleeding edge ;-) Only if its possible w/o a lot of work of course ... > In preferences, ad an new account and select opengroupware.org as a > driver. Hm. You based your work on the Noodle trunk branch? I've tried to replace all "opengroupware" references with "GroupDAV" in my branch. While I don't mind OGo publicity, I really think we should make this a "GroupDAV" connector. Will need to setup some Ubuntu ... ;-) Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From evolution@opengroupware.org Thu Aug 17 11:28:20 2006 From: evolution@opengroupware.org (Robert de Geus) Date: Thu, 17 Aug 2006 12:28:20 +0200 Subject: [OGo-Evolution] Groupdav website update In-Reply-To: References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> <1155761500.29859.19.camel@salsa-10-0-0-2> <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> <1155797189.32466.32.camel@salsa-10-0-0-2> Message-ID: <1155810500.5545.32.camel@salsa-10-1-0-237> Hi Helge, I would appreciate that, gr. Robert On Thu, 2006-08-17 at 11:21 +0200, Helge Hess wrote: > On Aug 17, 2006, at 08:46, Robert de Geus wrote: > > Is it possible to update the groupdav.org site? We could update the > > links (to the cvs) and name the new people? It would be nice if we > > also > > keep the old references and names. We might also make a page with the > > cookbook I wrote in a previous mail, so everyone can compile the > > connector easily. > > Sure, I can give you write access to the website. You won't be able > to update it directly (uses a weird and deprecated CMS), but you can > change the content in Svn. > > Greets, > Helge > -- > Helge Hess > http://docs.opengroupware.org/Members/helge/ > > From evolution@opengroupware.org Thu Aug 17 11:50:46 2006 From: evolution@opengroupware.org (Robert de Geus) Date: Thu, 17 Aug 2006 12:50:46 +0200 Subject: [OGo-Evolution] OGo - evolution connector uploaded in CVS In-Reply-To: <1E802981-108B-4DDF-8FEA-BC3C5E2A87F2@opengroupware.org> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> <1155761500.29859.19.camel@salsa-10-0-0-2> <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> <1155796389.32466.21.camel@salsa-10-0-0-2> <1E802981-108B-4DDF-8FEA-BC3C5E2A87F2@opengroupware.org> Message-ID: <1155811846.5545.53.camel@salsa-10-1-0-237> Hi Helge, On Thu, 2006-08-17 at 11:43 +0200, Helge Hess wrote: > On Aug 17, 2006, at 08:33, Robert de Geus wrote: > > Dapper has a lib dependency for evolution-plugin installed with > > version > > 2.6, the current connector looks for the 2.8 version. > > Could you elaborate? Is 2.6 and 2.8 API compatible? Will the > connector work for both? I guess so, we are now testing in our office on 2.6, but it is also in our plan to do an upstream merge a.s.a.p. to the main evolution tree. Shreyas could give more information on this. > How different is the 2.4 and 2.6 API? Is it viable to produce a 2.4 > variant? > Would be good if we could produce a connector which does not only > work against the bleeding edge ;-) Only if its possible w/o a lot of > work of course ... > It is not in our plan to do this. I think it is a matter of trying to compile it in 2.4, it is not part of our testing scheme. We control which versions runs on the systems of our users and we plan to upgrade as soon as this is possible. The reason is that the gnome desktop is stable, but that evolution is still our problem child. > > > In preferences, ad an new account and select opengroupware.org as a > > driver. > > Hm. You based your work on the Noodle trunk branch? I've tried to > replace all "opengroupware" references with "GroupDAV" in my branch. > While I don't mind OGo publicity, I really think we should make this > a "GroupDAV" connector. > I don't know what you mean, I am not programming, Shreyas is. Are you refering to the naming of objects? We are however trying to make an implementation of groupdav for opengroupware. Our users are going to be using both the web interface and evolution, so we want as many features available in evolution as in opengroupware as well as a data consistency between the two client interfaces. So maybe you could explain us where are the differences between opengroupware.org and groupdav... We might be able to take some issues in account. It would be very nice indeed if this implementation is fully groupdav compliant, but I hope you also understand that we need something that works and that our users understand. Because we are only testing against opengroupware we wont find any issues concerning other server implementations. > Will need to setup some Ubuntu ... ;-) > I guess so :), but you could always to give it a try to compile it for sarge, I just checked but the stable is still evolution 2.04 and unstable and testing is evolution 2.6. We are also running 2.6 in our office so there should be no problem doing that. greetings, Robert > Greets, > Helge > -- > Helge Hess > http://docs.opengroupware.org/Members/helge/ > > From evolution@opengroupware.org Thu Aug 17 12:13:37 2006 From: evolution@opengroupware.org (Helge Hess) Date: Thu, 17 Aug 2006 13:13:37 +0200 Subject: [OGo-Evolution] OGo - evolution connector uploaded in CVS In-Reply-To: <1155811846.5545.53.camel@salsa-10-1-0-237> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> <1155761500.29859.19.camel@salsa-10-0-0-2> <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> <1155796389.32466.21.camel@salsa-10-0-0-2> <1E802981-108B-4DDF-8FEA-BC3C5E2A87F2@opengroupware.org> <1155811846.5545.53.camel@salsa-10-1-0-237> Message-ID: <66F4CD52-4E90-48D2-8F74-D3BAC850F8DB@opengroupware.org> On Aug 17, 2006, at 12:50, Robert de Geus wrote: > I guess so, we are now testing in our office on 2.6, but it is also in > our plan to do an upstream merge a.s.a.p. to the main evolution tree. Nice! :-) > It is not in our plan to do this. I think it is a matter of trying to > compile it in 2.4, it is not part of our testing scheme. OK. >> Hm. You based your work on the Noodle trunk branch? I've tried to >> replace all "opengroupware" references with "GroupDAV" in my branch. >> While I don't mind OGo publicity, I really think we should make this >> a "GroupDAV" connector. >> > I don't know what you mean, I am not programming, Shreyas is. Are you > refering to the naming of objects? Function names and stuff in the connector itself, plus the labels in the UI. > We are however trying to make an > implementation of groupdav for opengroupware. Our users are going > to be > using both the web interface and evolution, so we want as many > features > available in evolution as in opengroupware as well as a data > consistency > between the two client interfaces. OK, do you plan to extend Evolution UI to access OGo features not available in Evo itself? > So maybe you could explain us where are the differences between > opengroupware.org and groupdav... We might be able to take some issues > in account. Hm, "differences"? Those are different entities :-) GroupDAV is a protocol which works against several servers, including OGo. Obviously it doesn't address features which are unique to OGo. > It would be very nice indeed if this implementation is fully > groupdav compliant, but I hope you also understand that we need > something that works and that our users understand. OK. The point of GroupDAV (as with any standard ...) is that the incident for other people to help with the connector gets raised. If its "just" an OGo connector, only OGo people are interested to fix bugs. Of course an OGo specific connector can integrate better with OGo which is also nice ;-) > Because we are only testing against opengroupware we wont find any > issues concerning other server implementations. Ack. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From evolution@opengroupware.org Thu Aug 17 13:44:18 2006 From: evolution@opengroupware.org (Shreyas Srinivasan) Date: Thu, 17 Aug 2006 18:14:18 +0530 Subject: [OGo-Evolution] OGo - evolution connector uploaded in CVS In-Reply-To: <1E802981-108B-4DDF-8FEA-BC3C5E2A87F2@opengroupware.org> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> <1155761500.29859.19.camel@salsa-10-0-0-2> <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> <1155796389.32466.21.camel@salsa-10-0-0-2> <1E802981-108B-4DDF-8FEA-BC3C5E2A87F2@opengroupware.org> Message-ID: <8f8004410608170544g2e2342a8qfd43dfc1483d4f7a@mail.gmail.com> On 8/17/06, Helge Hess wrote: > On Aug 17, 2006, at 08:33, Robert de Geus wrote: > Could you elaborate? Is 2.6 and 2.8 API compatible? Will the > connector work for both? > How different is the 2.4 and 2.6 API? Is it viable to produce a 2.4 > variant? The e-book and the e-cal api's are quite stable now since a large number of applications ranging from clock panel to open office use evolution-data-server. The code i committed has a 2.8 dependency, but that dependency is academical. Just change the version of evolution-plugins required in the configure script and everything should still work. > Would be good if we could produce a connector which does not only > work against the bleeding edge ;-) Only if its possible w/o a lot of > work of course ... It works well enough with the stable gnome version, trying to make it stop bleeding itself first ;-) > > In preferences, ad an new account and select opengroupware.org as a > > driver. > Hm. You based your work on the Noodle trunk branch? I've tried to > replace all "opengroupware" references with "GroupDAV" in my branch. > While I don't mind OGo publicity, I really think we should make this > a "GroupDAV" connector. Hmmm... either is ok with me. As long as the connector works with most GROUPDAV servers and implements some useful features in the Ogo server. -- Shreyas From evolution@opengroupware.org Thu Aug 17 13:54:41 2006 From: evolution@opengroupware.org (Shreyas Srinivasan) Date: Thu, 17 Aug 2006 18:24:41 +0530 Subject: [OGo-Evolution] OGo - evolution connector uploaded in CVS In-Reply-To: <66F4CD52-4E90-48D2-8F74-D3BAC850F8DB@opengroupware.org> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> <1155761500.29859.19.camel@salsa-10-0-0-2> <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> <1155796389.32466.21.camel@salsa-10-0-0-2> <1E802981-108B-4DDF-8FEA-BC3C5E2A87F2@opengroupware.org> <1155811846.5545.53.camel@salsa-10-1-0-237> <66F4CD52-4E90-48D2-8F74-D3BAC850F8DB@opengroupware.org> Message-ID: <8f8004410608170554y108cb091l44acb12f3e0feab3@mail.gmail.com> On 8/17/06, Helge Hess wrote: > On Aug 17, 2006, at 12:50, Robert de Geus wrote: > > I guess so, we are now testing in our office on 2.6, but it is also in > > our plan to do an upstream merge a.s.a.p. to the main evolution tree. > > Nice! :-) > > > It is not in our plan to do this. I think it is a matter of trying to > > compile it in 2.4, it is not part of our testing scheme. > > OK. > > >> Hm. You based your work on the Noodle trunk branch? I've tried to > >> replace all "opengroupware" references with "GroupDAV" in my branch. > >> While I don't mind OGo publicity, I really think we should make this > >> a "GroupDAV" connector. > >> > > I don't know what you mean, I am not programming, Shreyas is. Are you > > refering to the naming of objects? > > Function names and stuff in the connector itself, plus the labels in > the UI. > > > We are however trying to make an > > implementation of groupdav for opengroupware. Our users are going > > to be > > using both the web interface and evolution, so we want as many > > features > > available in evolution as in opengroupware as well as a data > > consistency > > between the two client interfaces. > > OK, do you plan to extend Evolution UI to access OGo features not > available in Evo itself? > > > So maybe you could explain us where are the differences between > > opengroupware.org and groupdav... We might be able to take some issues > > in account. > > It would be very nice indeed if this implementation is fully > > groupdav compliant, but I hope you also understand that we need > > something that works and that our users understand. > > OK. The point of GroupDAV (as with any standard ...) is that the > incident for other people to help with the connector gets raised. If > its "just" an OGo connector, only OGo people are interested to fix bugs. > Agree, we can have some way to discover features in OGo before using them, so the minimal subset would be Groupdav compatible but people can add custom server features to the backend. Right now that could be messy, let me figure out an elegant way of doing it. > Of course an OGo specific connector can integrate better with OGo > which is also nice ;-) Heh, true. I think its important to understand how many servers are Groupdav compatible and the kind of server specific features which they offer. I mean if we could integrate some useful features which are missing in the current Groupdav spec but have most servers implementing them , then that would rock big time. No idea how feasible that is though. > > Because we are only testing against opengroupware we wont find any > > issues concerning other server implementations. True, but i would like it to work with most GROUPDAV servers, just helps adoption as Helge stated. -- Shreyas From evolution@opengroupware.org Thu Aug 17 14:11:07 2006 From: evolution@opengroupware.org (Helge Hess) Date: Thu, 17 Aug 2006 15:11:07 +0200 Subject: [OGo-Evolution] OGo - evolution connector uploaded in CVS In-Reply-To: <8f8004410608170554y108cb091l44acb12f3e0feab3@mail.gmail.com> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> <1155761500.29859.19.camel@salsa-10-0-0-2> <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> <1155796389.32466.21.camel@salsa-10-0-0-2> <1E802981-108B-4DDF-8FEA-BC3C5E2A87F2@opengroupware.org> <1155811846.5545.53.camel@salsa-10-1-0-237> <66F4CD52-4E90-48D2-8F74-D3BAC850F8DB@opengroupware.org> <8f8004410608170554y108cb091l44acb12f3e0feab3@mail.gmail.com> Message-ID: On Aug 17, 2006, at 14:54, Shreyas Srinivasan wrote: > Agree, we can have some way to discover features in OGo before using > them, so the minimal subset would be Groupdav compatible but people > can add custom server features to the backend. Right now that could > be messy, let me figure out an elegant way of doing it. Would be nice, but possibly overkill. Don't know. >> Of course an OGo specific connector can integrate better with OGo >> which is also nice ;-) > > Heh, true. I think its important to understand how many servers are > Groupdav compatible and the kind of server specific features which > they offer. Oh, quite a few. In fact even a plain Apache WebDAV server should be a valid GroupDAV server! (though not a very clever one :-) > I mean if we could integrate some useful features which > are missing in the current Groupdav spec but have most servers > implementing them , then that would rock big time. No idea how > feasible that is though. It isn't very feasable. GroupDAV is a minimal spec which just covers iCalendar and vCard items and is fully WebDAV compatible. I would like to keep it that way. In fact iCalendar and vCard itself already have significant interoperability issues. (in fact OGo doesn't implement everything in iCal) >> > Because we are only testing against opengroupware we wont find any >> > issues concerning other server implementations. > True, but i would like it to work with most GROUPDAV servers, just > helps > adoption as Helge stated. Yeah, would be cool. But having additional OGo features in Evo would be very cool too! :-) Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From evolution@opengroupware.org Thu Aug 17 15:55:17 2006 From: evolution@opengroupware.org (Robert de Geus) Date: Thu, 17 Aug 2006 16:55:17 +0200 Subject: [OGo-Evolution] OGo - evolution connector uploaded in CVS In-Reply-To: <66F4CD52-4E90-48D2-8F74-D3BAC850F8DB@opengroupware.org> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> <1155761500.29859.19.camel@salsa-10-0-0-2> <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> <1155796389.32466.21.camel@salsa-10-0-0-2> <1E802981-108B-4DDF-8FEA-BC3C5E2A87F2@opengroupware.org> <1155811846.5545.53.camel@salsa-10-1-0-237> <66F4CD52-4E90-48D2-8F74-D3BAC850F8DB@opengroupware.org> Message-ID: <1155826517.5545.119.camel@salsa-10-1-0-237> Hi Helge, I have read the groupdav specs, in principle this is what we want to adhere to. It would be helpfull if we have an overview of the discrepancies between opengroupware and groupdav. I know you are in the original group who made the draft, so my guess is that opengroupware stays close. We don't need to look at how the client implements the specification, the client is always evolution. But there are difficulties, for example zidestore implements a directory structure, evolution does not allow for subdirectories of folders. But this is a client problem. I just went through the groupdav specs: Ad 3: we only implement events tasks and contacts, missing: journals and mails Ad 3.1 I dont understand the FREEBUSY implemntation, how does this apply in zidestore? Ad 3.1.1. Recurring items can be created in a new calendar item (webui), you can change each recurring item individually, the only operation which applies on the recurring list, is the delete all. The delete all applies also to the changed items. Also when changing one of the items in evolution, the zidestore server keeps the list so is still able to delete the whole list. Do we also allow this in evolution, or can this even be done? Ad 3.1.2. Alarms, at this moment in the current connector implementation we get all alarms of all calendar items stored on the zidestore server. If I look at the specification, it says no alarm, if I think what I would like to have is getting the alarm for my own calendar items (centrally stored), but not of the ones created by others. Ad 3.2. Tasks some things work, but we have not touched tasks yet. We have not observed users using tasks, so it is not high on our wish list. This will be implemented in a basic way as it looks now, just to make it working. Ad 3.2.1. Recurring Tasks, even more exotic, I don't see this implemented. Ad 3.2.2. Connected Tasks in the groupware server tasks are connected in projects, evolution has no way to display projects, so this probably will not be implemented Ad 3.3. Contacts high on the priority list, should support proper caching as described by the groupdav specs, categories should be displayed and usable. Does zidestore provide a way to see all defined categories? Does evolution have a way to display them and store them on the server? Ad 3.4. Journals What are journals???? Ad 4. Handling of UIDs, this is important for meetinging? At this moment the connector does not save the meeting names. One could think of displaying all employees for a meeting, or, allow for arbitrary names to be stored. What to do if users enter email addresses which dont exist in zidestore? In most companies, you would like to schedule with employees. I hope this give a starting point to figure out the conflicting points between opengroupware/evolution/groupdav It would be good to at least know them before making decisions. gr. Robert From evolution@opengroupware.org Fri Aug 18 00:00:47 2006 From: evolution@opengroupware.org (Nick Papadonis) Date: Thu, 17 Aug 2006 16:00:47 -0700 (PDT) Subject: [OGo-Evolution] OGo - evolution connector uploaded in CVS In-Reply-To: <1155796389.32466.21.camel@salsa-10-0-0-2> Message-ID: <20060817230048.5306.qmail@web54504.mail.yahoo.com> --- Robert de Geus wrote: > advanced a bit. At this moment we are testing for > evolution 2.6.1. This is great. Fedora Core 5 also includes 2.6.x by default. From evolution@opengroupware.org Fri Aug 18 00:52:50 2006 From: evolution@opengroupware.org (Helge Hess) Date: Fri, 18 Aug 2006 01:52:50 +0200 Subject: [OGo-Evolution] OGo - evolution connector uploaded in CVS In-Reply-To: <1155826517.5545.119.camel@salsa-10-1-0-237> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> <1155761500.29859.19.camel@salsa-10-0-0-2> <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> <1155796389.32466.21.camel@salsa-10-0-0-2> <1E802981-108B-4DDF-8FEA-BC3C5E2A87F2@opengroupware.org> <1155811846.5545.53.camel@salsa-10-1-0-237> <66F4CD52-4E90-48D2-8F74-D3BAC850F8DB@opengroupware.org> <1155826517.5545.119.camel@salsa-10-1-0-237> Message-ID: <9C6562CB-5796-467F-93E5-2E73B37A6B3D@opengroupware.org> On Aug 17, 2006, at 16:55, Robert de Geus wrote: > I have read the groupdav specs, in principle this is what we want to > adhere to. It would be helpfull if we have an overview of the > discrepancies between opengroupware and groupdav. The question can be mostly narrowed down to: a) what parts of iCalendar are supported by OGo - eg custom attributes X- - alarms - recurrences - attachments b) what parts of vCard are supported by OGo From the WebDAV part I can see two immediate issues: a) missing: vTODO PUT b) object creation is (incorrectly) bound to a single URL And more advanced stuff would need to go above WebDAV, eg for access control. > I know you are in the > original group who made the draft, so my guess is that opengroupware > stays close. The motivation was not to write an OGo specific protocol but one which could find acceptance by a large group of server and client vendors to avoid duplicate efforts. So the draft isn't tied a lot to OGo. > But there are difficulties, for example > zidestore implements a directory structure, evolution does not > allow for > subdirectories of folders. Yes, thats a tricky one (the flattening is copied from Outlook 2003). In fact Evo did support a directory structure <2.0. And I think the Evolution Connector for Exchange still has that, maybe we can reuse it? > Ad 3: we only implement events tasks and contacts, > missing: journals and mails OGo doesn't support the two anyway. Maybe we could map project/apt notes to journals, don't know. And mails are better handled by IMAP4 thought it would be cool if some "wizard" would setup a full OGo account, that is, GroupDAV things (events/tasks/contact) and IMAP4 stuff. > Ad 3.1 I dont understand the FREEBUSY implemntation, how does this > apply > in zidestore? Not sure what you mean, possibly this one: ---snip--- Since collections on the server can contain private items of other users, the user may only have access to the start and end time of an event. Instead of creating a special permission for this case, the server should deliver a valid iCalendar VFREEBUSY file containing exactly one busy record. ---snap--- Its not done this way by ZideStore. Which can be considered a bug. > Ad 3.1.1. Recurring items can be created in a new calendar item > (webui), > you can change each recurring item individually, the only operation > which applies on the recurring list, is the delete all. The delete all > applies also to the changed items. Also when changing one of the items > in evolution, the zidestore server keeps the list so is still able to > delete the whole list. Do we also allow this in evolution, or can this > even be done? This one is very tricky. The issue is that iCalendar(/Evo) uses 'calculated' recurrences while OGo always "flattens" recurrences on creation. I think there is little the connector can do about it, its ZideStore side stuff. If Evo PUTs a recurring event, ZideStore somehow needs to deal with it. The important thing is that the connector resyncs the collection after a PUT. So that if the server can choose to create multiple events from one (possibly connected using iCal exceptions, though ZideStore doesn't do this [yet]). > Ad 3.1.2. Alarms, at this moment in the current connector > implementation > we get all alarms of all calendar items stored on the zidestore > server. > If I look at the specification, it says no alarm, if I think what I > would like to have is getting the alarm for my own calendar items > (centrally stored), but not of the ones created by others. OGo WebUI only stores one alarm for all. OGo ZideStore does the same (in a different DB field! So WebUI alarms and Evo alarms are separate). This could be changed to be per-attendee, but it doesn't work this way right now. I'm not entirely sure but it might be best to keep alarms at the client and NOT push/retrieve them to the server at all. > Ad 3.2. Tasks some things work, but we have not touched tasks yet. We > have not observed users using tasks, so it is not high on our wish > list. > This will be implemented in a basic way as it looks now, just to > make it > working. Si. > Ad 3.2.1. Recurring Tasks, even more exotic, I don't see this > implemented. Its not supported by OGo anyways. > Ad 3.2.2. Connected Tasks in the groupware server tasks are > connected in > projects, evolution has no way to display projects, so this probably > will not be implemented It would be quite awesome if OGo projects could be added to Evo, possibly using some Evo UI plugin mechanism. Though this would be very much OGo specific. > Ad 3.3. Contacts high on the priority list, should support proper > caching as described by the groupdav specs, categories should be > displayed and usable. Yup. > Does zidestore provide a way to see all defined > categories? No. Are the categories predefined inside Evolution are not good enough? I think you can fetch the categories using XML-RPC, though it would probably be easy for me to add that to ZideStore too. => not GroupDAV in any case > Does evolution have a way to display them and store them on > the server? Sure, categories retrieval/storage should be fully supported. I think I already wrote that in another way. > Ad 3.4. Journals What are journals???? You don't use Outlook, eh? ;-) Journals are "activity logs". Somewhat like a blog or notes. Timed notes if you want. > Ad 4. Handling of UIDs, this is important for meetinging? iCalendar (like Outlook) uses email addresses as UIDs. Its important that all attendees have (unique) email addresses set for scheduling to work. I'm not sure whether we add additional IDs to iCal tags. > At this moment the connector does not save the meeting names. Not sure what you mean by that. > One could think of displaying all employees for a meeting, or, > allow for arbitrary names to be stored. This should work just fine - if emails are properly setup. > What to do if users enter email addresses which dont exist in > zidestore? ZideStore autocreates a private contact. > In most companies, you would like to schedule with employees. Yes. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From evolution@opengroupware.org Sat Aug 19 09:32:33 2006 From: evolution@opengroupware.org (Robert de Geus) Date: Sat, 19 Aug 2006 10:32:33 +0200 Subject: [OGo-Evolution] Groupdav implementation for the connector In-Reply-To: <9C6562CB-5796-467F-93E5-2E73B37A6B3D@opengroupware.org> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> <1155761500.29859.19.camel@salsa-10-0-0-2> <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> <1155796389.32466.21.camel@salsa-10-0-0-2> <1E802981-108B-4DDF-8FEA-BC3C5E2A87F2@opengroupware.org> <1155811846.5545.53.camel@salsa-10-1-0-237> <66F4CD52-4E90-48D2-8F74-D3BAC850F8DB@opengroupware.org> <1155826517.5545.119.camel@salsa-10-1-0-237> <9C6562CB-5796-467F-93E5-2E73B37A6B3D@opengroupware.org> Message-ID: <1155976354.9837.32.camel@salsa-10-0-0-2> Hi, After some internal discussion, we have decided to stick to the groupdav implementation for the evolution connector. The reason is that we want to give people the freedom to choose any client or server they want. We also have users on thunderbird, therefore it would be great if also thunderbird gets a groupdav implementation. It will then be crucial that both clients (evolution and thunderbird) can do, and will do the same thing. For this we need every server or client on the block to be able to talk to each other, Groupdav seems a good way to achieve this. Also we want to secure attention of a larger group for the maintenance and development of the connector (our company can only do this much, and can't fund the connector forever). We will therefore also rename objects in the code to remove all specific opengroupware names, and also in the server type, which you choose when you create an account, it should say "GroupDav" instead of opengroupware.org. Any suggestions about how to write it exactly? For the first version we are almost there, we have some bugs and will also implement the caching for the Contacts. This should get people and companies going. After this we will look at a more full featured version. We specifically invite people to test the connector and enter bugs in the bugzilla (http://bugzilla.opengroupware.org). Our testing schemes are unfortunately rather limited. At this moment we test on evolution 2.6.1 and zidestore 1.5. gr. Robert From evolution@opengroupware.org Sat Aug 19 11:04:39 2006 From: evolution@opengroupware.org (Helge Hess) Date: Sat, 19 Aug 2006 12:04:39 +0200 Subject: [OGo-Evolution] Groupdav implementation for the connector In-Reply-To: <1155976354.9837.32.camel@salsa-10-0-0-2> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> <1155761500.29859.19.camel@salsa-10-0-0-2> <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> <1155796389.32466.21.camel@salsa-10-0-0-2> <1E802981-108B-4DDF-8FEA-BC3C5E2A87F2@opengroupware.org> <1155811846.5545.53.camel@salsa-10-1-0-237> <66F4CD52-4E90-48D2-8F74-D3BAC850F8DB@opengroupware.org> <1155826517.5545.119.camel@salsa-10-1-0-237> <9C6562CB-5796-467F-93E5-2E73B37A6B3D@opengroupware.org> <1155976354.9837.32.camel@salsa-10-0-0-2> Message-ID: <553910E7-7DEF-47A2-BEF4-ABED0EFDE092@opengroupware.org> On Aug 19, 2006, at 10:32, Robert de Geus wrote: > We also have users on thunderbird, therefore it would be great if also > thunderbird gets a groupdav implementation. This should happen rather sooner than later. > Also we want to secure attention of a larger group for the maintenance > and development of the connector (our company can only do this > much, and > can't fund the connector forever). Obviously. > We will therefore also rename objects in the code to remove all > specific > opengroupware names, and also in the server type, which you choose > when > you create an account, it should say "GroupDav" instead of > opengroupware.org. Any suggestions about how to write it exactly? Thanks. GroupDAV please. > For the first version we are almost there, we have some bugs and will > also implement the caching for the Contacts. This should get people > and > companies going. Very good :-) > After this we will look at a more full featured version. > > We specifically invite people to test the connector and enter bugs in > the bugzilla (http://bugzilla.opengroupware.org). Our testing schemes > are unfortunately rather limited. At this moment we test on evolution > 2.6.1 and zidestore 1.5. Sounds good to me. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From evolution@opengroupware.org Sat Aug 19 13:33:48 2006 From: evolution@opengroupware.org (Janosch Rolles) Date: Sat, 19 Aug 2006 14:33:48 +0200 Subject: [OGo-Evolution] Groupdav implementation for the connector In-Reply-To: <1155976354.9837.32.camel@salsa-10-0-0-2> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> <1155761500.29859.19.camel@salsa-10-0-0-2> <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> <1155796389.32466.21.camel@salsa-10-0-0-2> <1E802981-108B-4DDF-8FEA-BC3C5E2A87F2@opengroupware.org> <1155811846.5545.53.camel@salsa-10-1-0-237> <66F4CD52-4E90-48D2-8F74-D3BAC850F8DB@opengroupware.org> <1155826517.5545.119.camel@salsa-10-1-0-237> <9C6562CB-5796-467F-93E5-2E73B37A6B3D@opengroupware.org> <1155976354.9837.32.camel@salsa-10-0-0-2> Message-ID: <1155990828.6167.3.camel@localhost> > We will therefore also rename objects in the code to remove all specific > opengroupware names, and also in the server type, which you choose when > you create an account, it should say "GroupDav" instead of > opengroupware.org. Any suggestions about how to write it exactly? I think the name should be "GroupDAV", right?? > > For the first version we are almost there, we have some bugs and will > also implement the caching for the Contacts. This should get people and > companies going. > > After this we will look at a more full featured version. > > We specifically invite people to test the connector and enter bugs in > the bugzilla (http://bugzilla.opengroupware.org). Our testing schemes > are unfortunately rather limited. At this moment we test on evolution > 2.6.1 and zidestore 1.5. I'm interested in testing the current version. Where can I get it? I guess the is some cvs or svn repository? Thanks Janosch From evolution@opengroupware.org Sat Aug 19 13:48:59 2006 From: evolution@opengroupware.org (Robert de Geus) Date: Sat, 19 Aug 2006 14:48:59 +0200 Subject: [OGo-Evolution] Groupdav implementation for the connector In-Reply-To: <1155990828.6167.3.camel@localhost> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> <1155761500.29859.19.camel@salsa-10-0-0-2> <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> <1155796389.32466.21.camel@salsa-10-0-0-2> <1E802981-108B-4DDF-8FEA-BC3C5E2A87F2@opengroupware.org> <1155811846.5545.53.camel@salsa-10-1-0-237> <66F4CD52-4E90-48D2-8F74-D3BAC850F8DB@opengroupware.org> <1155826517.5545.119.camel@salsa-10-1-0-237> <9C6562CB-5796-467F-93E5-2E73B37A6B3D@opengroupware.org> <1155976354.9837.32.camel@salsa-10-0-0-2> <1155990828.6167.3.camel@localhost> Message-ID: <1155991739.13062.5.camel@salsa-10-0-0-2> http://svn.opengroupware.org/OGoProjects/evolution/trunk/shreyas On Sat, 2006-08-19 at 14:33 +0200, Janosch Rolles wrote: > > We will therefore also rename objects in the code to remove all specific > > opengroupware names, and also in the server type, which you choose when > > you create an account, it should say "GroupDav" instead of > > opengroupware.org. Any suggestions about how to write it exactly? > > I think the name should be "GroupDAV", right?? > > > > > > For the first version we are almost there, we have some bugs and will > > also implement the caching for the Contacts. This should get people and > > companies going. > > > > After this we will look at a more full featured version. > > > > We specifically invite people to test the connector and enter bugs in > > the bugzilla (http://bugzilla.opengroupware.org). Our testing schemes > > are unfortunately rather limited. At this moment we test on evolution > > 2.6.1 and zidestore 1.5. > > > I'm interested in testing the current version. Where can I get it? I > guess the is some cvs or svn repository? > > > Thanks > > Janosch > From evolution@opengroupware.org Sat Aug 19 13:45:45 2006 From: evolution@opengroupware.org (Helge Hess) Date: Sat, 19 Aug 2006 14:45:45 +0200 Subject: [OGo-Evolution] Groupdav implementation for the connector In-Reply-To: <1155990828.6167.3.camel@localhost> References: <8f8004410608160111y7bd41372ka644839445b5ee34@mail.gmail.com> <8f8004410608161240q341b5424gc54926bbed903039@mail.gmail.com> <3452EC4D-FF4F-4985-B694-0C181F690ECC@opengroupware.org> <1155761500.29859.19.camel@salsa-10-0-0-2> <208443B3-E9B6-48BB-A1CE-1720AE5B9E75@opengroupware.org> <1155796389.32466.21.camel@salsa-10-0-0-2> <1E802981-108B-4DDF-8FEA-BC3C5E2A87F2@opengroupware.org> <1155811846.5545.53.camel@salsa-10-1-0-237> <66F4CD52-4E90-48D2-8F74-D3BAC850F8DB@opengroupware.org> <1155826517.5545.119.camel@salsa-10-1-0-237> <9C6562CB-5796-467F-93E5-2E73B37A6B3D@opengroupware.org> <1155976354.9837.32.camel@salsa-10-0-0-2> <1155990828.6167.3.camel@localhost> Message-ID: On Aug 19, 2006, at 14:33, Janosch Rolles wrote: > I think the name should be "GroupDAV", right?? Yes. > I'm interested in testing the current version. Where can I get it? I > guess the is some cvs or svn repository? http://svn.opengroupware.org/OGoProjects/evolution/trunk/shreyas/ Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From evolution@opengroupware.org Tue Aug 29 14:55:10 2006 From: evolution@opengroupware.org (Lorenzo Milesi) Date: Tue, 29 Aug 2006 15:55:10 +0200 Subject: [OGo-Evolution] Compile error Message-ID: <29c147bd0608290655tec2c99l515ca9b276b219f6@mail.gmail.com> Hi I was about to try the Evolution connector for OGo but I ran into a compile problem. The error is gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -DORBIT2=1 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libart-2.0 -I/usr/include/freetype2 -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/gconf/2 -I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib64/gnome-vfs-2.0/include -I/usr/include/gnome-keyring-1 -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2 -I/usr/include/libglade-2.0 -I/usr/include/libgnomeprintui-2.2 -I/usr/include/libgnomeprint-2.2 -I/usr/include/libsoup-2.2 -I/usr/include/evolution-data-server-1.6 -I/usr/include/evolution-2.6 -g -O2 -c e-cal-backend-ogo.c -MT e-cal-backend-ogo.lo -MD -MP -MF .deps/e-cal-backend-ogo.TPlo -fPIC -DPIC -o .libs/e-cal-backend-ogo.o e-cal-backend-ogo.c: In function 'e_cal_backend_ogo_class_init': e-cal-backend-ogo.c:1514: error: 'ECalBackendSyncClass' has no member named 'set_default_zone_sync' make[2]: *** [e-cal-backend-ogo.lo] Error 1 make[2]: Leaving directory `shreyas/calendar' The only strange thing I could notice during configure is ./configure: line 21132: OGO_COMPILE_WARNINGS: command not found I checked out right now rev 39. I'm using Evolution 2.6.2 on Gentoo AMD64. Did I miss something? Thanks Maxxer From evolution@opengroupware.org Tue Aug 29 15:01:48 2006 From: evolution@opengroupware.org (Shreyas Srinivasan) Date: Tue, 29 Aug 2006 19:31:48 +0530 Subject: [OGo-Evolution] Compile error In-Reply-To: <29c147bd0608290655tec2c99l515ca9b276b219f6@mail.gmail.com> References: <29c147bd0608290655tec2c99l515ca9b276b219f6@mail.gmail.com> Message-ID: <8f8004410608290701h3d0b5160j2f9ea4a14f6bd37@mail.gmail.com> On 8/29/06, Lorenzo Milesi wrote: > Hi > > I was about to try the Evolution connector for OGo but I ran into a > compile problem. > The error is > > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -DORBIT2=1 -pthread > -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include > -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include > -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 > -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libart-2.0 > -I/usr/include/freetype2 -I/usr/include/libgnomeui-2.0 > -I/usr/include/libgnome-2.0 -I/usr/include/gconf/2 > -I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-vfs-2.0 > -I/usr/lib64/gnome-vfs-2.0/include -I/usr/include/gnome-keyring-1 > -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 > -I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2 > -I/usr/include/libglade-2.0 -I/usr/include/libgnomeprintui-2.2 > -I/usr/include/libgnomeprint-2.2 -I/usr/include/libsoup-2.2 > -I/usr/include/evolution-data-server-1.6 -I/usr/include/evolution-2.6 > -g -O2 -c e-cal-backend-ogo.c -MT e-cal-backend-ogo.lo -MD -MP -MF > .deps/e-cal-backend-ogo.TPlo -fPIC -DPIC -o .libs/e-cal-backend-ogo.o > e-cal-backend-ogo.c: In function 'e_cal_backend_ogo_class_init': > e-cal-backend-ogo.c:1514: error: 'ECalBackendSyncClass' has no member > named 'set_default_zone_sync' > make[2]: *** [e-cal-backend-ogo.lo] Error 1 > make[2]: Leaving directory `shreyas/calendar' > > Ummm... Yes my current working version of evolution-data-server is 1.8. Amazingly the one of the very few things different between 1.6 and 1.8 is that api. Replace set_default_zone_sync with set_default_timezone_sync and it should work. This api is deprecated for the 1.8 release which is like in 20 days. So i am not sure whats the best way to deal with it, for now i am making it work with the bleeding version, but that one change should get it to work with other versions too. -- Shreyas From evolution@opengroupware.org Tue Aug 29 15:03:43 2006 From: evolution@opengroupware.org (Helge Hess) Date: Tue, 29 Aug 2006 16:03:43 +0200 Subject: [OGo-Evolution] Compile error In-Reply-To: <8f8004410608290701h3d0b5160j2f9ea4a14f6bd37@mail.gmail.com> References: <29c147bd0608290655tec2c99l515ca9b276b219f6@mail.gmail.com> <8f8004410608290701h3d0b5160j2f9ea4a14f6bd37@mail.gmail.com> Message-ID: On Aug 29, 2006, at 16:01, Shreyas Srinivasan wrote: > Replace set_default_zone_sync with set_default_timezone_sync and it > should > work. This api is deprecated for the 1.8 release which is like in > 20 days. So i > am not sure whats the best way to deal with it, for now i am making > it work > with the bleeding version, but that one change should get it to > work with other > versions too. Can't you do a simple #if evo_major >= 1 && evo_minor > 6 ... #else ... #endif ? Sounds like an easy to solve issue? :-) Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ From evolution@opengroupware.org Tue Aug 29 15:15:42 2006 From: evolution@opengroupware.org (Shreyas Srinivasan) Date: Tue, 29 Aug 2006 19:45:42 +0530 Subject: [OGo-Evolution] Compile error In-Reply-To: References: <29c147bd0608290655tec2c99l515ca9b276b219f6@mail.gmail.com> <8f8004410608290701h3d0b5160j2f9ea4a14f6bd37@mail.gmail.com> Message-ID: <8f8004410608290715q735c8065q31a24f0e074bee73@mail.gmail.com> On 8/29/06, Helge Hess wrote: > On Aug 29, 2006, at 16:01, Shreyas Srinivasan wrote: > > Replace set_default_zone_sync with set_default_timezone_sync and it > > should > > work. This api is deprecated for the 1.8 release which is like in > > 20 days. So i > > am not sure whats the best way to deal with it, for now i am making > > it work > > with the bleeding version, but that one change should get it to > > work with other > > versions too. > > Can't you do a simple > > #if evo_major >= 1 && evo_minor > 6 > ... > #else > ... > #endif > > ? Sounds like an easy to solve issue? :-) Sure i can, but that trunk was always a bleeding edge. So, for now a lot of such niceties aren't in place. They will be handled soon enough though. -- Shreyas CelAbrate your flaws From evolution@opengroupware.org Tue Aug 29 15:45:55 2006 From: evolution@opengroupware.org (Lorenzo Milesi) Date: Tue, 29 Aug 2006 16:45:55 +0200 Subject: [OGo-Evolution] Compile error In-Reply-To: <8f8004410608290715q735c8065q31a24f0e074bee73@mail.gmail.com> References: <29c147bd0608290655tec2c99l515ca9b276b219f6@mail.gmail.com> <8f8004410608290701h3d0b5160j2f9ea4a14f6bd37@mail.gmail.com> <8f8004410608290715q735c8065q31a24f0e074bee73@mail.gmail.com> Message-ID: <29c147bd0608290745w25f7f574y63eebe47e7d1480a@mail.gmail.com> > Sure i can, but that trunk was always a bleeding edge. > So, for now a lot of such niceties aren't in place. They > will be handled soon enough though. Is there a more stable repository, so I won't bother the list for every problem? :) Actually after your reply I managed to build, install and use the plugin. I could add an app with Evo and was correctly created on OGo, but I still can't see on Evo the appointments created on OGo. And again, in app properties on Evo the participant list is filled with "No name" participants, but at least they have the correct email address. Thanks again Maxxer From evolution@opengroupware.org Tue Aug 29 16:13:58 2006 From: evolution@opengroupware.org (Shreyas Srinivasan) Date: Tue, 29 Aug 2006 20:43:58 +0530 Subject: [OGo-Evolution] Compile error In-Reply-To: <29c147bd0608290745w25f7f574y63eebe47e7d1480a@mail.gmail.com> References: <29c147bd0608290655tec2c99l515ca9b276b219f6@mail.gmail.com> <8f8004410608290701h3d0b5160j2f9ea4a14f6bd37@mail.gmail.com> <8f8004410608290715q735c8065q31a24f0e074bee73@mail.gmail.com> <29c147bd0608290745w25f7f574y63eebe47e7d1480a@mail.gmail.com> Message-ID: <8f8004410608290813k50603d01x57ebe51dc1a93c36@mail.gmail.com> On 8/29/06, Lorenzo Milesi wrote: > > Sure i can, but that trunk was always a bleeding edge. > > So, for now a lot of such niceties aren't in place. They > > will be handled soon enough though. > > Is there a more stable repository, so I won't bother the list for > every problem? :) The stable one works only with 2.2. I wasnt aware that a lot of other people were stress testing this trunk, i will make sure it works for all. This way we can fix most possible issues as soon as possible. > Actually after your reply I managed to build, install and use the plugin. > I could add an app with Evo and was correctly created on OGo, but I > still can't see on Evo the appointments created on OGo. > And again, in app properties on Evo the participant list is filled > with "No name" participants, but at least they have the correct email > address. Ummm...Newly created items get downloaded when the client re-syncs which is not configurable, I think it refreshes every 10 mins or so. Thats one of the problems with e-d-s running as a daemon, difficult to set parameters from the ui. But it should download all those items after some time, i just tried it and it works perfectly. For the "No Name" issue, there is a bug filed for it. http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1778 Thanks for testing it out, its great to have active feedback so that we can make the connector as good as possible. Thanks, Shreyas From evolution@opengroupware.org Wed Aug 30 13:28:55 2006 From: evolution@opengroupware.org (Lorenzo Milesi) Date: Wed, 30 Aug 2006 14:28:55 +0200 Subject: [OGo-Evolution] Compile error In-Reply-To: <8f8004410608290813k50603d01x57ebe51dc1a93c36@mail.gmail.com> References: <29c147bd0608290655tec2c99l515ca9b276b219f6@mail.gmail.com> <8f8004410608290701h3d0b5160j2f9ea4a14f6bd37@mail.gmail.com> <8f8004410608290715q735c8065q31a24f0e074bee73@mail.gmail.com> <29c147bd0608290745w25f7f574y63eebe47e7d1480a@mail.gmail.com> <8f8004410608290813k50603d01x57ebe51dc1a93c36@mail.gmail.com> Message-ID: <29c147bd0608300528h2b26125bh2419df12ee000b2e@mail.gmail.com> > Ummm...Newly created items get downloaded when the client re-syncs > which is not configurable, I think it refreshes every 10 mins or so. Thats > one of the problems with e-d-s running as a daemon, difficult to set > parameters from the ui. But it should download all those items after > some time, i just tried it and it works perfectly. Mmhh... Then I must have done something wrong because I tried creating both a private and a group app but it doesn't get synced. I've Evolution open for something like one hour now! > Thanks for testing it out, its great to have active feedback so that we can > make the connector as good as possible. Glad to be helpful! I hope I can give you more feedback later on. Just to know, the connector just handles appointments, right? Thanks again maxxer From evolution@opengroupware.org Wed Aug 30 13:37:10 2006 From: evolution@opengroupware.org (Shreyas Srinivasan) Date: Wed, 30 Aug 2006 18:07:10 +0530 Subject: [OGo-Evolution] Compile error In-Reply-To: <29c147bd0608300528h2b26125bh2419df12ee000b2e@mail.gmail.com> References: <29c147bd0608290655tec2c99l515ca9b276b219f6@mail.gmail.com> <8f8004410608290701h3d0b5160j2f9ea4a14f6bd37@mail.gmail.com> <8f8004410608290715q735c8065q31a24f0e074bee73@mail.gmail.com> <29c147bd0608290745w25f7f574y63eebe47e7d1480a@mail.gmail.com> <8f8004410608290813k50603d01x57ebe51dc1a93c36@mail.gmail.com> <29c147bd0608300528h2b26125bh2419df12ee000b2e@mail.gmail.com> Message-ID: <8f8004410608300537v717a7edaq43178546b62b6a2b@mail.gmail.com> On 8/30/06, Lorenzo Milesi wrote: > > Ummm...Newly created items get downloaded when the client re-syncs > > which is not configurable, I think it refreshes every 10 mins or so. Thats > > one of the problems with e-d-s running as a daemon, difficult to set > > parameters from the ui. But it should download all those items after > > some time, i just tried it and it works perfectly. > > Mmhh... Then I must have done something wrong because I tried creating > both a private and a group app but it doesn't get synced. I've > Evolution open for something like one hour now! You can export OGO_DEBUG=1 and run evolution-data-server at terminal and you should get some debug spew which should tell you whats happening. If you are well verse with gdb, then i could help you debug too :-) > Just to know, the connector just handles appointments, right? Appointments and meetings, Although meetings have a CN bug which Helge fixed in the trunk, i will fix it in the connector too. -- Shreyas From evolution@opengroupware.org Thu Aug 31 13:35:32 2006 From: evolution@opengroupware.org (Lorenzo Milesi) Date: Thu, 31 Aug 2006 14:35:32 +0200 Subject: Not getting app (was Re: [OGo-Evolution] Compile error) Message-ID: <29c147bd0608310535o79669a3u11d3bc2328856f3f@mail.gmail.com> > You can export OGO_DEBUG=1 and run evolution-data-server at terminal > and you should get some debug spew which should tell you whats happening. I did the export and then run evolution-data-server The only relevant messages I see are: ** Message: Creating a new OGo Events Backend ... ** Message: Trying to conenct to server: maxxer, ... ** Message: Creating a new OGo TODO Backend ... ** Message: Trying to conenct to server: maxxer, ... ** Message: e-cal-backend-ogo.c:1172: Getting object list ((has-alarms-in-range? (make-time "20060831T122822Z") (make-time "20060831T220000Z"))) ** Message: e-cal-backend-ogo.c:1172: Getting object list ((has-alarms-in-range? (make-time "20060831T122822Z") (make-time "20060831T220000Z"))) Warning: reauthenticate! ** Message: Trying to conenct to server: maxxer, ... in server_log_handler ** Message: Trying to conenct to server: maxxer, ... in server_log_handler ** Message: e-cal-backend-ogo.c:1172: Getting object list ((and (occur-in-time-range? (make-time "20060830T220000Z") (make-time "20060831T220000Z")) )) in server_log_handler ** Message: e-cal-backend-ogo.c:1172: Getting object list ((and (occur-in-time-range? (make-time "20060827T220000Z") (make-time "20060901T220000Z")) )) in server_log_handler ** Message: e-cal-backend-ogo.c:1172: Getting object list ((and (occur-in-time-range? (make-time "20060827T220000Z") (make-time "20060903T220000Z")) )) in server_log_handler ** Message: e-cal-backend-ogo.c:1172: Getting object list ((and (occur-in-time-range? (make-time "20060730T220000Z") (make-time "20060910T220000Z")) )) in server_log_handler ** Message: e-cal-backend-ogo.c:1172: Getting object list ((and (occur-in-time-range? (make-time "20060731T220000Z") (make-time "20060831T220000Z")) )) in server_log_handler ** Message: e-cal-backend-ogo.c:1172: Getting object list (#f) in server_log_handler ** Message: e-cal-backend-ogo.c:1172: Getting object list ((and (occur-in-time-range? (make-time "20060806T220000Z") (make-time "20060807T220000Z")) )) in server_log_handler ** Message: e-cal-backend-ogo.c:1172: Getting object list ((and (occur-in-time-range? (make-time "20060806T220000Z") (make-time "20060811T220000Z")) )) in server_log_handler ** Message: e-cal-backend-ogo.c:1172: Getting object list ((and (occur-in-time-range? (make-time "20060806T220000Z") (make-time "20060813T220000Z")) )) in server_log_handler ** Message: e-cal-backend-ogo.c:1172: Getting object list ((and (occur-in-time-range? (make-time "20060813T220000Z") (make-time "20060814T220000Z")) )) in server_log_handler ** Message: e-cal-backend-ogo.c:1172: Getting object list ((and (occur-in-time-range? (make-time "20060813T220000Z") (make-time "20060818T220000Z")) )) in server_log_handler ** Message: e-cal-backend-ogo.c:1172: Getting object list ((and (occur-in-time-range? (make-time "20060813T220000Z") (make-time "20060820T220000Z")) )) in server_log_handler ** Message: e-cal-backend-ogo.c:1172: Getting object list ((and (occur-in-time-range? (make-time "20060820T220000Z") (make-time "20060821T220000Z")) )) in server_log_handler ** Message: e-cal-backend-ogo.c:1172: Getting object list ((and (occur-in-time-range? (make-time "20060820T220000Z") (make-time "20060825T220000Z")) )) in server_log_handler ** Message: e-cal-backend-ogo.c:1172: Getting object list ((and (occur-in-time-range? (make-time "20060820T220000Z") (make-time "20060827T220000Z")) )) ... and so on because of scrolling into calendar. > If you are well verse with gdb, then i could help you debug too :-) not much honestly :(