From evolution@opengroupware.org Thu Oct 7 21:38:19 2004 From: evolution@opengroupware.org (Benjamin Long) Date: Thu, 07 Oct 2004 16:38:19 -0400 Subject: [OGo-Evolution] Building Evolution Connector Message-ID: <1097181499.30159.4.camel@localhost.localdomain> I'm trying to build the connector for evolution. Reading the archives tells me that I am running into the same problem as someone else, caused by the changes in evo version 2.0. Any help with this would be greatly appreciated as I'm working on a rollout. Here's the end of my build log: e-book-backend-ogo.c: In function `e_book_backend_ogo_create_contact': e-book-backend-ogo.c:52: error: incompatible type for argument 3 of `e_data_book_respond_create' e-book-backend-ogo.c:52: error: too few arguments to function `e_data_book_respond_create' e-book-backend-ogo.c: In function `e_book_backend_ogo_remove_contacts': e-book-backend-ogo.c:63: error: incompatible type for argument 3 of `e_data_book_respond_remove_contacts' e-book-backend-ogo.c:63: error: too few arguments to function `e_data_book_respond_remove_contacts' e-book-backend-ogo.c: In function `e_book_backend_ogo_modify_contact': e-book-backend-ogo.c:75: error: incompatible type for argument 3 of `e_data_book_respond_modify' e-book-backend-ogo.c:75: error: too few arguments to function `e_data_book_respond_modify' e-book-backend-ogo.c: In function `e_book_backend_ogo_get_contact': e-book-backend-ogo.c:87: error: incompatible type for argument 3 of `e_data_book_respond_get_contact' e-book-backend-ogo.c:87: error: too few arguments to function `e_data_book_respond_get_contact' e-book-backend-ogo.c: In function `e_book_backend_ogo_get_contact_list': e-book-backend-ogo.c:98: error: incompatible type for argument 3 of `e_data_book_respond_get_contact_list' e-book-backend-ogo.c:98: error: too few arguments to function `e_data_book_respond_get_contact_list' e-book-backend-ogo.c: In function `e_book_backend_ogo_authenticate_user': e-book-backend-ogo.c:219: error: too few arguments to function `e_data_book_respond_authenticate_user' e-book-backend-ogo.c: In function `e_book_backend_ogo_get_supported_fields': e-book-backend-ogo.c:251: error: incompatible type for argument 3 of `e_data_book_respond_get_supported_fields' e-book-backend-ogo.c:251: error: too few arguments to function `e_data_book_respond_get_supported_fields' e-book-backend-ogo.c: In function `e_book_backend_ogo_remove': e-book-backend-ogo.c:288: error: too few arguments to function `e_data_book_respond_remove' e-book-backend-ogo.c: In function `e_book_backend_ogo_class_init': e-book-backend-ogo.c:362: warning: assignment from incompatible pointer type e-book-backend-ogo.c:363: warning: assignment from incompatible pointer type e-book-backend-ogo.c:364: warning: assignment from incompatible pointer type e-book-backend-ogo.c:365: warning: assignment from incompatible pointer type e-book-backend-ogo.c:366: warning: assignment from incompatible pointer type e-book-backend-ogo.c:369: warning: assignment from incompatible pointer type e-book-backend-ogo.c:370: warning: assignment from incompatible pointer type e-book-backend-ogo.c:371: warning: assignment from incompatible pointer type e-book-backend-ogo.c:372: warning: assignment from incompatible pointer type e-book-backend-ogo.c:373: warning: assignment from incompatible pointer type make[4]: *** [e-book-backend-ogo.lo] Error 1 make[4]: Leaving directory `/home/bflong/build/evolution-ogo-0.0.3/addressbook/backends/ogo' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/bflong/build/evolution-ogo-0.0.3/addressbook/backends' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/bflong/build/evolution-ogo-0.0.3/addressbook' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/bflong/build/evolution-ogo-0.0.3' make: *** [all] Error 2 -- Benjamin Long bflong@longbros.com From evolution@opengroupware.org Fri Oct 8 09:56:27 2004 From: evolution@opengroupware.org (Jean-Pascal Robiez) Date: Fri, 08 Oct 2004 10:56:27 +0200 Subject: [OGo-Evolution] Building Evolution Connector In-Reply-To: <1097181499.30159.4.camel@localhost.localdomain> References: <1097181499.30159.4.camel@localhost.localdomain> Message-ID: <1097225787.12957.5.camel@localhost> --=-WOHiVg4UE/ok+FUaotVa Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable hello, you need to patch e-book-backend-ogo.c to use this version of evolution, all backend funtion have to pass the opid parameter. I don't have access to cvs now so I can't make a diff but I join you the version of this file I use. hope this helps, JP Le jeudi 07 octobre 2004 =E0 16:38 -0400, Benjamin Long a =E9crit : > I'm trying to build the connector for evolution. Reading the archives > tells me that I am running into the same problem as someone else, caused > by the changes in evo version 2.0. Any help with this would be greatly > appreciated as I'm working on a rollout. Here's the end of my build log: >=20 > e-book-backend-ogo.c: In function `e_book_backend_ogo_create_contact': > e-book-backend-ogo.c:52: error: incompatible type for argument 3 of > `e_data_book_respond_create' > e-book-backend-ogo.c:52: error: too few arguments to function > `e_data_book_respond_create' > e-book-backend-ogo.c: In function `e_book_backend_ogo_remove_contacts': > e-book-backend-ogo.c:63: error: incompatible type for argument 3 of > `e_data_book_respond_remove_contacts' > e-book-backend-ogo.c:63: error: too few arguments to function > `e_data_book_respond_remove_contacts' > e-book-backend-ogo.c: In function `e_book_backend_ogo_modify_contact': > e-book-backend-ogo.c:75: error: incompatible type for argument 3 of > `e_data_book_respond_modify' > e-book-backend-ogo.c:75: error: too few arguments to function > `e_data_book_respond_modify' > e-book-backend-ogo.c: In function `e_book_backend_ogo_get_contact': > e-book-backend-ogo.c:87: error: incompatible type for argument 3 of > `e_data_book_respond_get_contact' > e-book-backend-ogo.c:87: error: too few arguments to function > `e_data_book_respond_get_contact' > e-book-backend-ogo.c: In function `e_book_backend_ogo_get_contact_list': > e-book-backend-ogo.c:98: error: incompatible type for argument 3 of > `e_data_book_respond_get_contact_list' > e-book-backend-ogo.c:98: error: too few arguments to function > `e_data_book_respond_get_contact_list' > e-book-backend-ogo.c: In function > `e_book_backend_ogo_authenticate_user': > e-book-backend-ogo.c:219: error: too few arguments to function > `e_data_book_respond_authenticate_user' > e-book-backend-ogo.c: In function > `e_book_backend_ogo_get_supported_fields': > e-book-backend-ogo.c:251: error: incompatible type for argument 3 of > `e_data_book_respond_get_supported_fields' > e-book-backend-ogo.c:251: error: too few arguments to function > `e_data_book_respond_get_supported_fields' > e-book-backend-ogo.c: In function `e_book_backend_ogo_remove': > e-book-backend-ogo.c:288: error: too few arguments to function > `e_data_book_respond_remove' > e-book-backend-ogo.c: In function `e_book_backend_ogo_class_init': > e-book-backend-ogo.c:362: warning: assignment from incompatible pointer > type > e-book-backend-ogo.c:363: warning: assignment from incompatible pointer > type > e-book-backend-ogo.c:364: warning: assignment from incompatible pointer > type > e-book-backend-ogo.c:365: warning: assignment from incompatible pointer > type > e-book-backend-ogo.c:366: warning: assignment from incompatible pointer > type > e-book-backend-ogo.c:369: warning: assignment from incompatible pointer > type > e-book-backend-ogo.c:370: warning: assignment from incompatible pointer > type > e-book-backend-ogo.c:371: warning: assignment from incompatible pointer > type > e-book-backend-ogo.c:372: warning: assignment from incompatible pointer > type > e-book-backend-ogo.c:373: warning: assignment from incompatible pointer > type > make[4]: *** [e-book-backend-ogo.lo] Error 1 > make[4]: Leaving directory > `/home/bflong/build/evolution-ogo-0.0.3/addressbook/backends/ogo' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory > `/home/bflong/build/evolution-ogo-0.0.3/addressbook/backends' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory > `/home/bflong/build/evolution-ogo-0.0.3/addressbook' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/bflong/build/evolution-ogo-0.0.3' > make: *** [all] Error 2 >=20 > --=20 > Benjamin Long > bflong@longbros.com >=20 --=20 Jean-Pascal Robiez iXnos 12, rue du g=E9n=E9ral Delestraint 75016 PARIS tel: +33(0)1 40 71 60 69 mobile : +33 (0)6 62 61 68 34 This message and any attachments are confidential and intended solely for the addressees. If you receive this message in error, please delete it and immediately notify the sender. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorized use, copying or dissemination is prohibited. E-mails are susceptible to alteration. Neither Ixnos nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. --=-WOHiVg4UE/ok+FUaotVa Content-Disposition: attachment; filename=e-book-backend-ogo.c Content-Type: text/x-csrc; name=e-book-backend-ogo.c; charset=ISO-8859-15 Content-Transfer-Encoding: base64 LyogLSotIE1vZGU6IEM7IHRhYi13aWR0aDogMjsgaW5kZW50LXRhYnMtbW9kZTogdDsgYy1iYXNp Yy1vZmZzZXQ6IDIgLSotICovDQovKg0KICogQXV0aG9yOg0KICogICBKZW5zIFJlaW1hbm4gPGN0 cm9uQGRlbnRyYXNzaS5kZT4NCiAqDQogKiBCYXNlZCBvbiB3b3JrIGZyb206DQogKiAgIFNpdmFp YWggTmFsbGFnYXRsYSAoc25hbGxhZ2F0bGFAbm92ZWxsLmNvbSkNCiAqDQogKi8NCg0KI2lmZGVm IEhBVkVfQ09ORklHX0gNCiNpbmNsdWRlIDxjb25maWcuaD4NCiNlbmRpZg0KDQoNCg0KI2luY2x1 ZGUgPGxpYmVib29rL2UtY29udGFjdC5oPg0KI2luY2x1ZGUgPGxpYmdub21lL2dub21lLWkxOG4u aD4NCiNpbmNsdWRlIDxsaWJlZGF0YXNlcnZlci9lLXNleHAuaD4NCiNpbmNsdWRlIDxsaWJlZGF0 YS1ib29rL2UtYm9vay1iYWNrZW5kLXNleHAuaD4NCiNpbmNsdWRlIDxsaWJlZGF0YS1ib29rL2Ut Ym9vay1iYWNrZW5kLXN1bW1hcnkuaD4NCiNpbmNsdWRlIDxsaWJlZGF0YS1ib29rL2UtZGF0YS1i b29rLmg+DQojaW5jbHVkZSA8bGliZWRhdGEtYm9vay9lLWRhdGEtYm9vay12aWV3Lmg+DQojaW5j bHVkZSAiZS1ib29rLWJhY2tlbmQtb2dvLmgiDQojaW5jbHVkZSA8bGliZ25vbWUvZ25vbWUtaTE4 bi5oPg0KDQojaW5jbHVkZSA8bGlic291cC9zb3VwLmg+DQoNCiNpbmNsdWRlICJvZ28tY29ubmVj dGlvbi5oIg0KDQpzdGF0aWMgRUJvb2tCYWNrZW5kQ2xhc3MgKmVfYm9va19iYWNrZW5kX29nb19w YXJlbnRfY2xhc3M7DQoNCnN0cnVjdCBfRUJvb2tCYWNrZW5kT0dPUHJpdmF0ZSB7DQoJY2hhciAq dXJpOw0KCU9HT0Nvbm5lY3Rpb24gKiBjb25uZWN0aW9uOw0KfTsNCg0KI2RlZmluZSBFTEVNRU5U X1RZUEVfU0lNUExFIDB4MDENCiNkZWZpbmUgRUxFTUVOVF9UWVBFX0NPTVBMRVggMHgwMiAvKiBm aWVsZHMgd2hpY2ggcmVxdWlyZSBleHBsaWNpdCBmdW5jdGlvbnMgdG8gc2V0IHZhbHVlcyBpbnRv IEVDb250YWN0IGFuZCBFR3dJdGVtICovDQoNCg0KDQpzdGF0aWMgdm9pZA0KZV9ib29rX2JhY2tl bmRfb2dvX2NyZWF0ZV9jb250YWN0IChFQm9va0JhY2tlbmQgKmJhY2tlbmQsDQoJCQkJCQkJCQkJ CQkJCQkJCSBFRGF0YUJvb2sgKmJvb2ssDQoJCQkJCQkJCQkJCQkJCQkJCSBndWludDMyIG9waWQs DQoJCQkJCQkJCQkJCQkJCQkJCSBjb25zdCBjaGFyICp2Y2FyZCApDQp7DQoJRUJvb2tCYWNrZW5k T0dPICpvZ287DQoJDQoJb2dvID0gRV9CT09LX0JBQ0tFTkRfT0dPIChiYWNrZW5kKTsNCgkNCgll X2RhdGFfYm9va19yZXNwb25kX2NyZWF0ZShib29rLCBvcGlkLEdOT01FX0V2b2x1dGlvbl9BZGRy ZXNzYm9va19PdGhlckVycm9yLCBOVUxMKTsgIA0KfQ0KDQpzdGF0aWMgdm9pZA0KZV9ib29rX2Jh Y2tlbmRfb2dvX3JlbW92ZV9jb250YWN0cyAoRUJvb2tCYWNrZW5kICpiYWNrZW5kLA0KCQkJCQkJ CQkJCQkJCQkJCQkJRURhdGFCb29rICAgICpib29rLA0KCQkJCQkJCQkJCQkJCQkJCQkJZ3VpbnQz MiBvcGlkLA0KCQkJCQkJCQkJCQkJCQkJCQkJR0xpc3QgKmlkX2xpc3QgICAgKQ0Kew0KICANCglF Qm9va0JhY2tlbmRPR08gKm9nbzsNCglvZ28gPSBFX0JPT0tfQkFDS0VORF9PR08gKGJhY2tlbmQp Ow0KCWVfZGF0YV9ib29rX3Jlc3BvbmRfcmVtb3ZlX2NvbnRhY3RzIChib29rLCBvcGlkLCBHTk9N RV9Fdm9sdXRpb25fQWRkcmVzc2Jvb2tfT3RoZXJFcnJvciwgTlVMTCk7DQp9DQoNCg0Kc3RhdGlj IHZvaWQNCmVfYm9va19iYWNrZW5kX29nb19tb2RpZnlfY29udGFjdCAoRUJvb2tCYWNrZW5kICpi YWNrZW5kLA0KCQkJCQkJCQkJCQkJCQkJCQkgRURhdGFCb29rICAgICpib29rLA0KCQkJCQkJCQkJ CQkJCQkJCQkgZ3VpbnQzMiBvcGlkLA0KCQkJCQkJCQkJCQkJCQkJCQkgY29uc3QgY2hhciAqdmNh cmQgICAgKQ0KewkNCglFQm9va0JhY2tlbmRPR08gKm9nbzsNCg0KCW9nbyA9IEVfQk9PS19CQUNL RU5EX09HTyAoYmFja2VuZCk7DQoJZV9kYXRhX2Jvb2tfcmVzcG9uZF9tb2RpZnkgKGJvb2ssIG9w aWQsIEdOT01FX0V2b2x1dGlvbl9BZGRyZXNzYm9va19PdGhlckVycm9yLCBOVUxMKTsNCgkNCn0N Cg0Kc3RhdGljIHZvaWQNCmVfYm9va19iYWNrZW5kX29nb19nZXRfY29udGFjdCAoRUJvb2tCYWNr ZW5kICpiYWNrZW5kLA0KCQkJCQkJCQkJCQkJCQkJCUVEYXRhQm9vayAgICAqYm9vaywNCgkJCQkJ CQkJCQkJCQkJCQlndWludDMyIG9waWQsDQoJCQkJCQkJCQkJCQkJCQkJY29uc3QgY2hhciAqaWQg ICApDQp7DQoJRUJvb2tCYWNrZW5kT0dPICpvZ287DQoNCglvZ28gPSAgRV9CT09LX0JBQ0tFTkRf T0dPIChiYWNrZW5kKTsNCgllX2RhdGFfYm9va19yZXNwb25kX2dldF9jb250YWN0IChib29rLCBv cGlkLCBHTk9NRV9Fdm9sdXRpb25fQWRkcmVzc2Jvb2tfT3RoZXJFcnJvciwgTlVMTCk7DQp9DQoN CnN0YXRpYyB2b2lkDQplX2Jvb2tfYmFja2VuZF9vZ29fZ2V0X2NvbnRhY3RfbGlzdCAoRUJvb2tC YWNrZW5kICpiYWNrZW5kLA0KCQkJCQkJCQkJCQkJCQkJCQkJIEVEYXRhQm9vayAgICAqYm9vaywN CgkJCQkJCQkJCQkJCQkJCQkJCSBndWludDMyIG9waWQsDQoJCQkJCQkJCQkJCQkJCQkJCQkgY29u c3QgY2hhciAqcXVlcnkgKQ0KeyAgDQoJRUJvb2tCYWNrZW5kT0dPICpvZ287DQoJb2dvID0gRV9C T09LX0JBQ0tFTkRfT0dPIChiYWNrZW5kKTsNCg0KCWVfZGF0YV9ib29rX3Jlc3BvbmRfZ2V0X2Nv bnRhY3RfbGlzdCAoYm9vaywgb3BpZCwgR05PTUVfRXZvbHV0aW9uX0FkZHJlc3Nib29rX0NvbnRh Y3ROb3RGb3VuZCwgTlVMTCApOw0KDQp9DQoNCnZvaWQgYWRkX29uZV9jb250YWN0ICggT0dPUmVz dWx0ICogcmVzdWx0LCBFRGF0YUJvb2tWaWV3ICogYm9va192aWV3ICkNCnsNCg0KCS8vIFdlIG5l ZWQgdG8ga25vdyB3aGljaCBsb2NhbGUgdGhlIHNlcnZlciBoYXMNCglnY2hhciAqIGJ1ZmZlcjsN CglidWZmZXIgPSBnX2xvY2FsZV90b191dGY4ICggcmVzdWx0LT5tZXNzYWdlLT5yZXNwb25zZS5i b2R5LCByZXN1bHQtPm1lc3NhZ2UtPnJlc3BvbnNlLmxlbmd0aCwgTlVMTCwgTlVMTCwgTlVMTCAp Ow0KDQoJLy8gSW5zZXJ0IGEgY29udGFjdA0KCUVDb250YWN0ICogY29udGFjdDsNCg0KCWNvbnRh Y3QgPSBlX2NvbnRhY3RfbmV3X2Zyb21fdmNhcmQgKCBidWZmZXIgKTsNCg0KCWdfZnJlZSAoIGJ1 ZmZlciApOw0KDQoJaWYgKCBjb250YWN0ICkNCgkJew0KCQkJZV9kYXRhX2Jvb2tfdmlld19ub3Rp ZnlfdXBkYXRlICggYm9va192aWV3LCBjb250YWN0ICk7DQoJCQlnX29iamVjdF91bnJlZihjb250 YWN0KTsNCgkJfQ0KfQ0KIA0Kc3RhdGljIHZvaWQNCmVfYm9va19iYWNrZW5kX29nb19zdGFydF9i b29rX3ZpZXcgKEVCb29rQmFja2VuZCAgKmJhY2tlbmQsDQoJCQkJICAgIEVEYXRhQm9va1ZpZXcg KmJvb2tfdmlldykNCnsNCg0KCUVCb29rQmFja2VuZE9HTyAqb2dvOw0KDQoJZ19wcmludCAoICJl X2Jvb2tfYmFja2VuZF9vZ29fc3RhcnRfYm9va192aWV3XG4iICk7DQoNCglvZ28gID0gRV9CT09L X0JBQ0tFTkRfT0dPIChiYWNrZW5kKTsNCiAgICANCgkvLyBTZW5kIGEgc3RhcnRpbmcgbWVzc2Fn ZQ0KCWVfZGF0YV9ib29rX3ZpZXdfbm90aWZ5X3N0YXR1c19tZXNzYWdlIChib29rX3ZpZXcsIF8o IlNlYXJjaGluZy4uLiIpKTsNCg0KCU9HT1Jlc3VsdExpbmtzICogcmVzdWx0TGlua3M7DQoJT0dP UmVzdWx0ICogcmVzdWx0Ow0KDQoJLy8gZmV0Y2ggdGhlIGxpc3Qgb2YgaHJlZnMgZm9yIHRoZSBh Y2NvdW50IFVSTA0KCXJlc3VsdExpbmtzID0gb2dvX2Nvbm5lY3Rpb25fbGlzdF9ocmVmcyAoIG9n by0+cHJpdi0+Y29ubmVjdGlvbiwgIiIgKTsNCg0KCS8vIEFib3J0IG9uIGZhaWx1cmUNCiAJaWYg KCBvZ29fcmVzdWx0X2ZhaWxlZCAoIE9HT19SRVNVTFQocmVzdWx0TGlua3MpICkgKQ0KCQl7DQoJ CQlnX3ByaW50ICggIkVycm9yIG9jY3VyZWQhXG4iICk7DQoJCQkvLyBOb3RpZnkgZXJyb3INCgkJ CWVfZGF0YV9ib29rX3ZpZXdfbm90aWZ5X2NvbXBsZXRlICggYm9va192aWV3LCBHTk9NRV9Fdm9s dXRpb25fQWRkcmVzc2Jvb2tfUmVwb3NpdG9yeU9mZmxpbmUgKTsNCgkJCWdfb2JqZWN0X3VucmVm ICggR19PQkpFQ1QocmVzdWx0TGlua3MpICk7DQoJCQlyZXR1cm47DQoJCX0NCg0KCUdMaXN0ICog Y3VycmVudDsNCgkvLyBpdGVyYXRlIG92ZXIgdGhlIGxpc3Qgb2YgaHJlZnMgLi4uDQoJZm9yICgg Y3VycmVudCA9IHJlc3VsdExpbmtzLT5saW5rczsgY3VycmVudDsgY3VycmVudCA9IGN1cnJlbnQt Pm5leHQgKQ0KCQl7DQoNCgkJCXJlc3VsdCA9IG9nb19yZXN1bHRfbmV3ICgpOw0KCQkJLy8gLi4u IGFuZCBmZXRjaCB0aGVtDQoJCQkvKg0KCQkJICogbm90IHZlcnkgZ29vZCAoPyEpIHdlIGdldCB0 aGUgY29tcGxldGUgaHJlZiEgbWlnaHQgYmUgc29tZXdoZXJlIG91dHNpZGUgdGhlIGJhc2UgdXJp IQ0KCQkJICogc2hvdWxkIHdlIHRydXN0IGl0Pw0KCQkJICovDQoJCQlvZ29fY29ubmVjdGlvbl9z ZW5kX3JlcXVlc3QgKCBvZ28tPnByaXYtPmNvbm5lY3Rpb24sIHJlc3VsdCwgIkdFVCIsIGN1cnJl bnQtPmRhdGEsIE5VTEwsIDAgKTsNCg0KCQkJLy8gaWYgbm90IGZhaWxlZCAuLi4gYWRkIHRvIGJv b2sNCgkJCWlmICggIW9nb19yZXN1bHRfZmFpbGVkICggT0dPX1JFU1VMVChyZXN1bHQpICkgKQ0K CQkJCXsNCgkJCQkJYWRkX29uZV9jb250YWN0ICggcmVzdWx0LCBib29rX3ZpZXcgKTsNCgkJCQl9 DQoJCQllbHNlDQoJCQkJew0KCQkJCQlnX3ByaW50ICggIkZldGNoIGZhaWxlZCFcbiIgKTsNCgkJ CQl9DQoNCgkJCWdfb2JqZWN0X3VucmVmICggR19PQkpFQ1QocmVzdWx0KSApOw0KCQl9DQoNCgln X29iamVjdF91bnJlZiAoIEdfT0JKRUNUKHJlc3VsdExpbmtzKSApOw0KDQoJLy8gTm90aWZ5IHN1 Y2Nlc3MNCgllX2RhdGFfYm9va192aWV3X25vdGlmeV9jb21wbGV0ZSAoYm9va192aWV3LCBHTk9N RV9Fdm9sdXRpb25fQWRkcmVzc2Jvb2tfU3VjY2Vzcyk7DQp9ICAgICANCiAgDQpzdGF0aWMgdm9p ZA0KZV9ib29rX2JhY2tlbmRfb2dvX3N0b3BfYm9va192aWV3IChFQm9va0JhY2tlbmQgICpiYWNr ZW5kLA0KCQkJCQkgRURhdGFCb29rVmlldyAqYm9va192aWV3KQ0Kew0KCWdfcHJpbnQgKCAiZV9i b29rX2JhY2tlbmRfb2dvX3N0b3BfYm9va192aWV3XG4iICk7DQp9DQoNCnN0YXRpYyB2b2lkDQpl X2Jvb2tfYmFja2VuZF9vZ29fZ2V0X2NoYW5nZXMgKEVCb29rQmFja2VuZCAqYmFja2VuZCwNCgkJ CQkgICAgICBFRGF0YUJvb2sgICAgKmJvb2ssDQoJCQkJICAgICAgY29uc3QgY2hhciAqY2hhbmdl X2lkICApDQp7DQoNCgkvKiBGSVhNRSA6IHByb3ZpZGUgaW1wbG1lbnRhdGlvbiAqLw0KfQ0KDQoN CnN0YXRpYyB2b2lkDQplX2Jvb2tfYmFja2VuZF9vZ29fYXV0aGVudGljYXRlX3VzZXIgKEVCb29r QmFja2VuZCAqYmFja2VuZCwNCgkJCQkJICAgIEVEYXRhQm9vayAgICAqYm9vaywNCgkJCQkJCWd1 aW50MzIgb3BpZCwNCgkJCQkJICAgIGNvbnN0IGNoYXIgKnVzZXIsDQoJCQkJCSAgICBjb25zdCBj aGFyICpwYXNzd2QsDQoJCQkJCSAgICBjb25zdCBjaGFyICphdXRoX21ldGhvZCkNCnsNCglFQm9v a0JhY2tlbmRPR08gKm9nbzsNCglFQm9va0JhY2tlbmRPR09Qcml2YXRlICpwcml2Ow0KDQoJZ19w cmludCAoICJlX2Jvb2tfYmFja2VuZF9vZ29fYXV0aGVudGljYXRlX3VzZXIgKCA/LCA/LCAlcywg JXMsICVzIClcbiIsIHVzZXIsIHBhc3N3ZCwgYXV0aF9tZXRob2QgKTsNCg0KCW9nbyA9IEVfQk9P S19CQUNLRU5EX09HTyAoYmFja2VuZCk7DQoJcHJpdiA9IG9nby0+cHJpdjsNCg0KCW9nb19jb25u ZWN0aW9uX2F1dGhlbnRpY2F0ZSAoIHByaXYtPmNvbm5lY3Rpb24sIHVzZXI/dXNlcjoiIiwgcGFz c3dkP3Bhc3N3ZDoiIiApOw0KDQoJZV9kYXRhX2Jvb2tfcmVzcG9uZF9hdXRoZW50aWNhdGVfdXNl ciAoYm9vaywgIG9waWQsIEdOT01FX0V2b2x1dGlvbl9BZGRyZXNzYm9va19TdWNjZXNzKTsgIA0K fQ0KDQp0eXBlZGVmIHN0cnVjdCB7DQoJY2hhciAqIG5hbWU7DQoJaW50IGZpZWxkX2lkOw0KfSBG aWVsZEluZm87DQoNCkZpZWxkSW5mbyBzdXBwb3J0ZWRfZmllbGRzIFtdID0gew0KCXsgIlVJRCIs IEVfQ09OVEFDVF9VSUQgfSwNCgl7ICJOYW1lIiwgRV9DT05UQUNUX0ZVTExfTkFNRSB9LA0KCXsg IkZpbGUgYXMiLCBFX0NPTlRBQ1RfRklMRV9BUyB9LA0KCXsgIkdpdmVuIE5hbWUiLCBFX0NPTlRB Q1RfR0lWRU5fTkFNRSB9LA0KCXsgIkZhbWlseSBOYW1lIiwgRV9DT05UQUNUX0ZBTUlMWV9OQU1F IH0sDQoJeyAiTmlja25hbWUiLCBFX0NPTlRBQ1RfTklDS05BTUUgfSwNCgl7IE5VTEwgfQ0KfTsN Cg0Kc3RhdGljIHZvaWQNCmVfYm9va19iYWNrZW5kX29nb19nZXRfc3VwcG9ydGVkX2ZpZWxkcyAo RUJvb2tCYWNrZW5kICpiYWNrZW5kLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBFRGF0YUJvb2sgICAgKmJvb2ssDQoJCQkJCQkJCQkJIGd1aW50MzIgb3BpZCApDQog ICAgICAgICAgICAgICAgICANCnsNCglHTGlzdCAqZmllbGRzID0gTlVMTDsNCg0KCUZpZWxkSW5m byAqIGZpOw0KDQoJZm9yICggZmkgPSBzdXBwb3J0ZWRfZmllbGRzOyBmaS0+bmFtZTsgZmkrKyAp DQoJCWZpZWxkcyA9IGdfbGlzdF9hcHBlbmQgKCBmaWVsZHMsIGdfc3RyZHVwICggZV9jb250YWN0 X2ZpZWxkX25hbWUgKCBmaS0+ZmllbGRfaWQgKSApICk7DQoJDQoJZV9kYXRhX2Jvb2tfcmVzcG9u ZF9nZXRfc3VwcG9ydGVkX2ZpZWxkcyAoYm9vaywNCgkJCQkJCQkJCQkJICBvcGlkLA0KCQkJCQkJ CQkJCQkgIEdOT01FX0V2b2x1dGlvbl9BZGRyZXNzYm9va19TdWNjZXNzLA0KCQkJCQkJCQkJCQkg IGZpZWxkcyk7DQoNCgkvLwlyZXR1cm4gR05PTUVfRXZvbHV0aW9uX0FkZHJlc3Nib29rX1N1Y2Nl c3M7DQp9DQogIA0KDQpzdGF0aWMgR05PTUVfRXZvbHV0aW9uX0FkZHJlc3Nib29rX0NhbGxTdGF0 dXMNCmVfYm9va19iYWNrZW5kX29nb19sb2FkX3NvdXJjZSAoRUJvb2tCYWNrZW5kICAgICAgICAg ICAqYmFja2VuZCwNCgkJCQkgICAgICBFU291cmNlICAgICAgICAgICAgICAgICpzb3VyY2UsDQoJ CQkJICAgICAgZ2Jvb2xlYW4gICAgICAgICAgICAgICAgb25seV9pZl9leGlzdHMpDQp7DQoJRUJv b2tCYWNrZW5kT0dPICpvZ287DQoJRUJvb2tCYWNrZW5kT0dPUHJpdmF0ZSAqcHJpdjsNCg0KCWdf cHJpbnQgKCAiZV9ib29rX2JhY2tlbmRfb2dvX2xvYWRfc291cmNlXG4iICk7DQoNCglvZ28gPSBF X0JPT0tfQkFDS0VORF9PR08gKGJhY2tlbmQpOw0KCXByaXYgPSBvZ28tPnByaXY7DQoNCglnY2hh ciAqIHVyaSA9IGVfc291cmNlX2dldF91cmkgKCBzb3VyY2UgKTsNCg0KCW9nb19jb25uZWN0aW9u X3NldF9iYXNlX3VyaSAoIG9nby0+cHJpdi0+Y29ubmVjdGlvbiwgdXJpICk7DQoNCglnX2ZyZWUg KCB1cmkgKTsNCg0KCXJldHVybiBHTk9NRV9Fdm9sdXRpb25fQWRkcmVzc2Jvb2tfU3VjY2VzczsN Cn0NCg0Kc3RhdGljIHZvaWQNCmVfYm9va19iYWNrZW5kX29nb19yZW1vdmUgKEVCb29rQmFja2Vu ZCAqYmFja2VuZCwNCgkJCQlnaW50MzIJb3BpZCwNCgkJCQkgRURhdGFCb29rICAgICAgICAqYm9v aykNCnsNCglFQm9va0JhY2tlbmRPR08gKiBvZ287DQoJaW50IHN0YXR1czsNCiAgDQoJb2dvID0g RV9CT09LX0JBQ0tFTkRfT0dPIChiYWNrZW5kKTsNCg0KCWVfZGF0YV9ib29rX3Jlc3BvbmRfcmVt b3ZlIChib29rLCBvcGlkLCBHTk9NRV9Fdm9sdXRpb25fQWRkcmVzc2Jvb2tfT3RoZXJFcnJvcik7 ICAgIA0KfQ0KDQoNCnN0YXRpYyBjaGFyICoNCmVfYm9va19iYWNrZW5kX29nb19nZXRfc3RhdGlj X2NhcGFiaWxpdGllcyAoRUJvb2tCYWNrZW5kICpiYWNrZW5kKQ0Kew0KCXJldHVybiBnX3N0cmR1 cCgibmV0LGJ1bGstcmVtb3Zlcyxkby1pbml0aWFsLXF1ZXJ5LHJlYWRvbmx5LHJlYWQtb25seSIp Ow0KfQ0KDQpzdGF0aWMgdm9pZCANCmVfYm9va19iYWNrZW5kX29nb19nZXRfc3VwcG9ydGVkX2F1 dGhfbWV0aG9kcyAoRUJvb2tCYWNrZW5kICpiYWNrZW5kLCBFRGF0YUJvb2sgKmJvb2spDQp7DQoJ LypGSVhNRSAgcHJvdmlkZSBpbXBsZW1lbnRhdGlvbiovICANCn0NCg0KDQovKioNCiAqIGVfYm9v a19iYWNrZW5kX29nb19uZXc6DQogKi8NCkVCb29rQmFja2VuZCAqDQplX2Jvb2tfYmFja2VuZF9v Z29fbmV3ICh2b2lkKQ0Kew0KCUVCb29rQmFja2VuZE9HTyAqYmFja2VuZDsNCg0KCWdfcHJpbnQg KCAiZV9ib29rX2JhY2tlbmRfb2dvX25ld1xuIiApOw0KCQ0KCWJhY2tlbmQgPSBnX29iamVjdF9u ZXcgKEVfVFlQRV9CT09LX0JBQ0tFTkRfT0dPLCBOVUxMKTsNCg0KCXJldHVybiBFX0JPT0tfQkFD S0VORCAoYmFja2VuZCk7DQp9DQoNCnN0YXRpYyB2b2lkDQplX2Jvb2tfYmFja2VuZF9vZ29fZGlz cG9zZSAoR09iamVjdCAqb2JqZWN0KQ0Kew0KCUVCb29rQmFja2VuZE9HTyAqb2dvOw0KDQoJb2dv ID0gRV9CT09LX0JBQ0tFTkRfT0dPIChvYmplY3QpOw0KDQoJaWYgKG9nby0+cHJpdikNCgkJew0K CQkJaWYgKG9nby0+cHJpdi0+dXJpKQ0KCQkJCXsNCgkJCQkJZ19mcmVlIChvZ28tPnByaXYtPnVy aSk7DQoJCQkJCW9nby0+cHJpdi0+dXJpID0gTlVMTDsNCgkJCQl9DQoNCgkJCWlmICggb2dvLT5w cml2LT5jb25uZWN0aW9uICkNCgkJCQlnX29iamVjdF91bnJlZiAoIEdfT0JKRUNUICggb2dvLT5w cml2LT5jb25uZWN0aW9uICkgKTsNCg0KCQkJZ19mcmVlIChvZ28tPnByaXYpOw0KCQkJb2dvLT5w cml2ID0gTlVMTDsNCgl9DQoJR19PQkpFQ1RfQ0xBU1MgKGVfYm9va19iYWNrZW5kX29nb19wYXJl bnRfY2xhc3MpLT5kaXNwb3NlIChvYmplY3QpOw0KfQ0KDQpzdGF0aWMgdm9pZA0KZV9ib29rX2Jh Y2tlbmRfb2dvX2NsYXNzX2luaXQgKEVCb29rQmFja2VuZE9HT0NsYXNzICprbGFzcykNCnsNCg0K CWdfcHJpbnQgKCAiZV9ib29rX2JhY2tlbmRfb2dvX2NsYXNzX2luaXRcbiIgKTsNCg0KCUdPYmpl Y3RDbGFzcyAgKm9iamVjdF9jbGFzcyA9IEdfT0JKRUNUX0NMQVNTIChrbGFzcyk7DQoJRUJvb2tC YWNrZW5kQ2xhc3MgKnBhcmVudF9jbGFzczsNCg0KDQoJZV9ib29rX2JhY2tlbmRfb2dvX3BhcmVu dF9jbGFzcyA9IGdfdHlwZV9jbGFzc19wZWVrX3BhcmVudCAoa2xhc3MpOw0KDQoJcGFyZW50X2Ns YXNzID0gRV9CT09LX0JBQ0tFTkRfQ0xBU1MgKGtsYXNzKTsNCg0KCS8qIFNldCB0aGUgdmlydHVh bCBtZXRob2RzLiAqLw0KCXBhcmVudF9jbGFzcy0+bG9hZF9zb3VyY2UgICAgICAgICAgICAgPSBl X2Jvb2tfYmFja2VuZF9vZ29fbG9hZF9zb3VyY2U7DQoJcGFyZW50X2NsYXNzLT5nZXRfc3RhdGlj X2NhcGFiaWxpdGllcyA9IGVfYm9va19iYWNrZW5kX29nb19nZXRfc3RhdGljX2NhcGFiaWxpdGll czsNCg0KCXBhcmVudF9jbGFzcy0+Y3JlYXRlX2NvbnRhY3QgICAgICAgICAgPSBlX2Jvb2tfYmFj a2VuZF9vZ29fY3JlYXRlX2NvbnRhY3Q7DQoJcGFyZW50X2NsYXNzLT5yZW1vdmVfY29udGFjdHMg ICAgICAgICA9IGVfYm9va19iYWNrZW5kX29nb19yZW1vdmVfY29udGFjdHM7DQoJcGFyZW50X2Ns YXNzLT5tb2RpZnlfY29udGFjdCAgICAgICAgICA9IGVfYm9va19iYWNrZW5kX29nb19tb2RpZnlf Y29udGFjdDsNCglwYXJlbnRfY2xhc3MtPmdldF9jb250YWN0ICAgICAgICAgICAgID0gZV9ib29r X2JhY2tlbmRfb2dvX2dldF9jb250YWN0Ow0KCXBhcmVudF9jbGFzcy0+Z2V0X2NvbnRhY3RfbGlz dCAgICAgICAgPSBlX2Jvb2tfYmFja2VuZF9vZ29fZ2V0X2NvbnRhY3RfbGlzdDsNCglwYXJlbnRf Y2xhc3MtPnN0YXJ0X2Jvb2tfdmlldyAgICAgICAgID0gZV9ib29rX2JhY2tlbmRfb2dvX3N0YXJ0 X2Jvb2tfdmlldzsNCglwYXJlbnRfY2xhc3MtPnN0b3BfYm9va192aWV3ICAgICAgICAgID0gZV9i b29rX2JhY2tlbmRfb2dvX3N0b3BfYm9va192aWV3Ow0KCXBhcmVudF9jbGFzcy0+Z2V0X2NoYW5n ZXMgICAgICAgICAgICAgPSBlX2Jvb2tfYmFja2VuZF9vZ29fZ2V0X2NoYW5nZXM7DQoJcGFyZW50 X2NsYXNzLT5hdXRoZW50aWNhdGVfdXNlciAgICAgICA9IGVfYm9va19iYWNrZW5kX29nb19hdXRo ZW50aWNhdGVfdXNlcjsNCglwYXJlbnRfY2xhc3MtPmdldF9zdXBwb3J0ZWRfZmllbGRzICAgID0g ZV9ib29rX2JhY2tlbmRfb2dvX2dldF9zdXBwb3J0ZWRfZmllbGRzOw0KCXBhcmVudF9jbGFzcy0+ Z2V0X3N1cHBvcnRlZF9hdXRoX21ldGhvZHMgPSBlX2Jvb2tfYmFja2VuZF9vZ29fZ2V0X3N1cHBv cnRlZF9hdXRoX21ldGhvZHM7DQoJcGFyZW50X2NsYXNzLT5yZW1vdmUgICAgICAgICAgICAgICAg ICA9IGVfYm9va19iYWNrZW5kX29nb19yZW1vdmU7DQoJb2JqZWN0X2NsYXNzLT5kaXNwb3NlICAg ICAgICAgICAgICAgICA9IGVfYm9va19iYWNrZW5kX29nb19kaXNwb3NlOw0KfQ0KDQpzdGF0aWMg dm9pZA0KZV9ib29rX2JhY2tlbmRfb2dvX2luaXQgKEVCb29rQmFja2VuZE9HTyAqYmFja2VuZCkN CnsNCglFQm9va0JhY2tlbmRPR09Qcml2YXRlICpwcml2Ow0KCQ0KCWdfcHJpbnQgKCAiZV9ib29r X2JhY2tlbmRfb2dvX2luaXRcbiIgKTsNCg0KCXByaXYgPSBnX25ldzAgKEVCb29rQmFja2VuZE9H T1ByaXZhdGUsIDEpOw0KDQoJYmFja2VuZC0+cHJpdiA9IHByaXY7DQoNCglwcml2LT5jb25uZWN0 aW9uID0gb2dvX2Nvbm5lY3Rpb25fbmV3ICgpOw0KfQ0KDQoNCi8qKg0KICogZV9ib29rX2JhY2tl bmRfb2dvX2dldF90eXBlOg0KICovDQpHVHlwZQ0KZV9ib29rX2JhY2tlbmRfb2dvX2dldF90eXBl ICh2b2lkKQ0Kew0KCXN0YXRpYyBHVHlwZSB0eXBlID0gMDsNCg0KCWlmICghIHR5cGUpIHsNCgkJ R1R5cGVJbmZvIGluZm8gPSB7DQoJCQlzaXplb2YgKEVCb29rQmFja2VuZE9HT0NsYXNzKSwNCgkJ CU5VTEwsIC8qIGJhc2VfY2xhc3NfaW5pdCAqLw0KCQkJTlVMTCwgLyogYmFzZV9jbGFzc19maW5h bGl6ZSAqLw0KCQkJKEdDbGFzc0luaXRGdW5jKSAgZV9ib29rX2JhY2tlbmRfb2dvX2NsYXNzX2lu aXQsDQoJCQlOVUxMLCAvKiBjbGFzc19maW5hbGl6ZSAqLw0KCQkJTlVMTCwgLyogY2xhc3NfZGF0 YSAqLw0KCQkJc2l6ZW9mIChFQm9va0JhY2tlbmRPR08pLA0KCQkJMCwgICAgLyogbl9wcmVhbGxv Y3MgKi8NCgkJCShHSW5zdGFuY2VJbml0RnVuYykgZV9ib29rX2JhY2tlbmRfb2dvX2luaXQNCgkJ fTsNCg0KCQl0eXBlID0gZ190eXBlX3JlZ2lzdGVyX3N0YXRpYyAoRV9UWVBFX0JPT0tfQkFDS0VO RCwgIkVCb29rQmFja2VuZE9HTyIsICZpbmZvLCAwKTsNCgl9DQoNCglyZXR1cm4gdHlwZTsNCn0N Cg== --=-WOHiVg4UE/ok+FUaotVa-- From evolution@opengroupware.org Fri Oct 8 10:37:48 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Fri, 08 Oct 2004 11:37:48 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution Message-ID: <1097228268.2640.0.camel@dhcp246> Hello, the last month I have been working for my company on the perl daemon I proposed earlier on this list. We now have basic read only calendar and contact support for Evolution<->OGo. As proposed earlier, the daemon is located between the Ximian Connector for Exchange (2.0) and ZideStore. It mangles data when needed. Some comments on the list suggested that this was a bad idea and that any such attempts would better be aimed at modifying either the connector or zidestore. However, as my company needs this connection and we our programmers are not skilled enough in either C or Objective C, we started this way. Helge Hess said earlier on this list that although ZideStore developpers plan to work on connector 2.0 support, it will take a while before they start on that. Therefore we started our own attempt. We see this daemon as something temporarily. At this moment it will provide users with the possibility to connect Evolution to an OpenGroupware.org server. We hope that later on this daemon will help ZideStore or other developpers to find out what exactly needs to be adjusted in order to make ZideStore compatible with the 2.0 connector. Another possibility is that other people can use this information to make a modified version of the Exchange connector. The daemon currently makes it possible to view your Calendar items and Contacts stored in OpenGroupware. Some very simple and quite unfinished task support is also implemented. By default this is disabled because it can cause long delays in the Calendar display. Calendar items seem quite OK, although it can be a bit slow if you store lots of items (>300). Contacts also seem to work fine. There is still lots of work here, but at least we finished some of the most important parts. We could use more developpers. Using the daemon is quite simple. Download the perl script from http://oracle.toltech.nl/~erik/ex2ogo-0.1.pl Edit the config section at the beginning of the file. Start the script and set your evolution exchange to connect to the daemon on it's listening port. Disable SSL and use plaintext passwords. Fill in the host and the port that ex2ogo is running on. In all cases I have seen the OWA path should be /zidestore. Press the arrow next to your exchange account in the Mail display of Evolution. It should now ask for your password and after that you should be able to turn on (mark the checkbox) the calendar. It seems that you don't need to go to Mail if you set evolution to remember your password. You can also view your contacts. What doesn't work yet; i.e.: what needs to be done in the short future: - Support for SUBSCRIBE; to make evolution update it's contact view (restart required now) - Finish support for tasks - Implement write support - Fix any bugs you people encounter :) If you'd like to help out: send a mail to me so that we can coordinate the work a bit. Feel free to take a look in the code, it is quite well commented. greetings, Erik Romijn From evolution@opengroupware.org Fri Oct 8 10:44:58 2004 From: evolution@opengroupware.org (Helge Hess) Date: Fri, 8 Oct 2004 11:44:58 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <1097228268.2640.0.camel@dhcp246> References: <1097228268.2640.0.camel@dhcp246> Message-ID: Hi Erik, really cool hack! :-) On Oct 8, 2004, at 11:37, Erik Romijn wrote: > We hope that later on this daemon will help > ZideStore or other developpers to find out what exactly needs to be > adjusted in order to make ZideStore compatible with the 2.0 connector. Yes, I think this should help a lot (though reading Perl code isn't much better than reading HTTP traffic ;-). > Calendar items seem quite OK, although it can be a bit slow if you > store > lots of items (>300). Contacts also seem to work fine. It would be cool if the script would maintain an offline cache of the data for both, offline use and increased speed. This would make it a valuable tool even when ZideStore supports all the API. > What doesn't work yet; i.e.: what needs to be done in the short future: > - Support for SUBSCRIBE; to make evolution update it's contact view > (restart required now) Yes, SOPE supports the subscribe extension and has an object to track the requests. But ZideStore doesn't send out notifications currently. The is a small tool in SOPE/sope-core/samples called httpu_notify.m which you might want to take a look at. > If you'd like to help out: send a mail to me so that we can coordinate > the work a bit. Feel free to take a look in the code, it is quite well > commented. Thanks a lot for your work! Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Fri Oct 8 11:08:38 2004 From: evolution@opengroupware.org (Jens Reimann) Date: Fri, 08 Oct 2004 10:08:38 -0000 Subject: [OGo-Evolution] Building Evolution Connector Message-ID: <20041008100839.8BA7324AF5E@flux.dentrassi.de> Hi, I just tried to patch the OGO cvs with the patch you attached, but my cvs access seems to be broken ... maybe helge can have a look at it ;-) so i can do this on the weekend ... btw. does anyone know where to get FC2 evolution 2.0 rpms which i can use for testing? jens evolution@opengroupware.org wrote: > hello, > > you need to patch e-book-backend-ogo.c to use this version of evolution, > all backend funtion have to pass the opid parameter. I don't have access > to cvs now so I can't make a diff but I join you the version of this > file I use. > > hope this helps, > > JP > > > > Le jeudi 07 octobre 2004 =E0 16:38 -0400, Benjamin Long a =E9crit : > > I'm trying to build the connector for evolution. Reading the archives > > tells me that I am running into the same problem as someone else, caused > > by the changes in evo version 2.0. Any help with this would be greatly > > appreciated as I'm working on a rollout. Here's the end of my build log: > > > > e-book-backend-ogo.c: In function `e_book_backend_ogo_create_contact': > > e-book-backend-ogo.c:52: error: incompatible type for argument 3 of > > `e_data_book_respond_create' > > e-book-backend-ogo.c:52: error: too few arguments to function > > `e_data_book_respond_create' > > e-book-backend-ogo.c: In function `e_book_backend_ogo_remove_contacts': > > e-book-backend-ogo.c:63: error: incompatible type for argument 3 of > > `e_data_book_respond_remove_contacts' > > e-book-backend-ogo.c:63: error: too few arguments to function > > `e_data_book_respond_remove_contacts' > > e-book-backend-ogo.c: In function `e_book_backend_ogo_modify_contact': > > e-book-backend-ogo.c:75: error: incompatible type for argument 3 of > > `e_data_book_respond_modify' > > e-book-backend-ogo.c:75: error: too few arguments to function > > `e_data_book_respond_modify' > > e-book-backend-ogo.c: In function `e_book_backend_ogo_get_contact': > > e-book-backend-ogo.c:87: error: incompatible type for argument 3 of > > `e_data_book_respond_get_contact' > > e-book-backend-ogo.c:87: error: too few arguments to function > > `e_data_book_respond_get_contact' > > e-book-backend-ogo.c: In function `e_book_backend_ogo_get_contact_list': > > e-book-backend-ogo.c:98: error: incompatible type for argument 3 of > > `e_data_book_respond_get_contact_list' > > e-book-backend-ogo.c:98: error: too few arguments to function > > `e_data_book_respond_get_contact_list' > > e-book-backend-ogo.c: In function > > `e_book_backend_ogo_authenticate_user': > > e-book-backend-ogo.c:219: error: too few arguments to function > > `e_data_book_respond_authenticate_user' > > e-book-backend-ogo.c: In function > > `e_book_backend_ogo_get_supported_fields': > > e-book-backend-ogo.c:251: error: incompatible type for argument 3 of > > `e_data_book_respond_get_supported_fields' > > e-book-backend-ogo.c:251: error: too few arguments to function > > `e_data_book_respond_get_supported_fields' > > e-book-backend-ogo.c: In function `e_book_backend_ogo_remove': > > e-book-backend-ogo.c:288: error: too few arguments to function > > `e_data_book_respond_remove' > > e-book-backend-ogo.c: In function `e_book_backend_ogo_class_init': > > e-book-backend-ogo.c:362: warning: assignment from incompatible pointer > > type > > e-book-backend-ogo.c:363: warning: assignment from incompatible pointer > > type > > e-book-backend-ogo.c:364: warning: assignment from incompatible pointer > > type > > e-book-backend-ogo.c:365: warning: assignment from incompatible pointer > > type > > e-book-backend-ogo.c:366: warning: assignment from incompatible pointer > > type > > e-book-backend-ogo.c:369: warning: assignment from incompatible pointer > > type > > e-book-backend-ogo.c:370: warning: assignment from incompatible pointer > > type > > e-book-backend-ogo.c:371: warning: assignment from incompatible pointer > > type > > e-book-backend-ogo.c:372: warning: assignment from incompatible pointer > > type > > e-book-backend-ogo.c:373: warning: assignment from incompatible pointer > > type > > make[4]: *** [e-book-backend-ogo.lo] Error 1 > > make[4]: Leaving directory > > `/home/bflong/build/evolution-ogo-0.0.3/addressbook/backends/ogo' > > make[3]: *** [all-recursive] Error 1 > > make[3]: Leaving directory > > `/home/bflong/build/evolution-ogo-0.0.3/addressbook/backends' > > make[2]: *** [all-recursive] Error 1 > > make[2]: Leaving directory > > `/home/bflong/build/evolution-ogo-0.0.3/addressbook' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/home/bflong/build/evolution-ogo-0.0.3' > > make: *** [all] Error 2 > > > > -- > > Benjamin Long > > bflong@longbros.com > > > -- > Jean-Pascal Robiez > iXnos > 12, rue du g=E9n=E9ral Delestraint > 75016 PARIS > tel: +33(0)1 40 71 60 69 > mobile : +33 (0)6 62 61 68 34 > > This message and any attachments are confidential and intended solely > for the addressees. If you receive this message in error, please delete it > and immediately notify the sender. If the reader of this message is not > the intended recipient, you are hereby notified that any unauthorized use, > copying or dissemination is prohibited. > E-mails are susceptible to alteration. Neither Ixnos nor any of its > subsidiaries or affiliates shall be liable for the message if altered, > changed or falsified. > From evolution@opengroupware.org Fri Oct 8 11:13:41 2004 From: evolution@opengroupware.org (Helge Hess) Date: Fri, 8 Oct 2004 12:13:41 +0200 Subject: [OGo-Evolution] Building Evolution Connector In-Reply-To: <20041008100839.8BA7324AF5E@flux.dentrassi.de> References: <20041008100839.8BA7324AF5E@flux.dentrassi.de> Message-ID: Hi Jens, On Oct 8, 2004, at 12:08, Jens Reimann wrote: > I just tried to patch the OGO cvs with the patch you attached, but my > cvs > access seems to be broken ... as you may have noticed you moved to Subversion ;-) The Evolution code was moved to: http://svn.opengroupware.org/OGoProjects/evolution/trunk/ (replace svn. with developer. for write access) Frank will get back to you with an Svn account and instructions. best regards, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Fri Oct 8 13:04:01 2004 From: evolution@opengroupware.org (Jens Reimann) Date: Fri, 08 Oct 2004 12:04:01 -0000 Subject: [OGo-Evolution] Building Evolution Connector Message-ID: <20041008120402.38E8124AF6B@flux.dentrassi.de> Hi Helge, wow ... well I really had less time the last months for OGO ... *g* anyway, I always wanted to try out SVN ... so let's go :-) jens evolution@opengroupware.org wrote: > Hi Jens, > > On Oct 8, 2004, at 12:08, Jens Reimann wrote: > > I just tried to patch the OGO cvs with the patch you attached, but my > > cvs > > access seems to be broken ... > > as you may have noticed you moved to Subversion ;-) > > The Evolution code was moved to: > http://svn.opengroupware.org/OGoProjects/evolution/trunk/ > > (replace svn. with developer. for write access) > > Frank will get back to you with an Svn account and instructions. > > best regards, > Helge > -- > http://docs.opengroupware.org/Members/helge/ > OpenGroupware.org > > -- > OpenGroupware.org Evolution > evolution@opengroupware.org > http://mail.opengroupware.org/mailman/listinfo/evolution > > From evolution@opengroupware.org Fri Oct 8 15:11:35 2004 From: evolution@opengroupware.org (Benjamin Long) Date: Fri, 08 Oct 2004 10:11:35 -0400 Subject: [OGo-Evolution] Building Evolution Connector In-Reply-To: <1097225787.12957.5.camel@localhost> References: <1097181499.30159.4.camel@localhost.localdomain> <1097225787.12957.5.camel@localhost> Message-ID: <1097244695.8857.2.camel@localhost.localdomain> On Fri, 2004-10-08 at 10:56 +0200, Jean-Pascal Robiez wrote: > hello, >=20 > you need to patch e-book-backend-ogo.c to use this version of evolution, > all backend funtion have to pass the opid parameter. I don't have access > to cvs now so I can't make a diff but I join you the version of this > file I use. >=20 > hope this helps, >=20 > JP >=20 >=20 >=20 > Le jeudi 07 octobre 2004 =E0 16:38 -0400, Benjamin Long a =E9crit : > > I'm trying to build the connector for evolution. Reading the archives > > tells me that I am running into the same problem as someone else, cause= d > > by the changes in evo version 2.0. Any help with this would be greatly > > appreciated as I'm working on a rollout. Here's the end of my build log= : > >=20 > > e-book-backend-ogo.c: In function `e_book_backend_ogo_create_contact': > > e-book-backend-ogo.c:52: error: incompatible type for argument 3 of > > `e_data_book_respond_create' > > e-book-backend-ogo.c:52: error: too few arguments to function > > `e_data_book_respond_create' > > e-book-backend-ogo.c: In function `e_book_backend_ogo_remove_contacts': > > e-book-backend-ogo.c:63: error: incompatible type for argument 3 of > > `e_data_book_respond_remove_contacts' > > e-book-backend-ogo.c:63: error: too few arguments to function > > `e_data_book_respond_remove_contacts' > > e-book-backend-ogo.c: In function `e_book_backend_ogo_modify_contact': > > e-book-backend-ogo.c:75: error: incompatible type for argument 3 of > > `e_data_book_respond_modify' > > e-book-backend-ogo.c:75: error: too few arguments to function > > `e_data_book_respond_modify' > > e-book-backend-ogo.c: In function `e_book_backend_ogo_get_contact': > > e-book-backend-ogo.c:87: error: incompatible type for argument 3 of > > `e_data_book_respond_get_contact' > > e-book-backend-ogo.c:87: error: too few arguments to function > > `e_data_book_respond_get_contact' > > e-book-backend-ogo.c: In function `e_book_backend_ogo_get_contact_list'= : > > e-book-backend-ogo.c:98: error: incompatible type for argument 3 of > > `e_data_book_respond_get_contact_list' > > e-book-backend-ogo.c:98: error: too few arguments to function > > `e_data_book_respond_get_contact_list' > > e-book-backend-ogo.c: In function > > `e_book_backend_ogo_authenticate_user': > > e-book-backend-ogo.c:219: error: too few arguments to function > > `e_data_book_respond_authenticate_user' > > e-book-backend-ogo.c: In function > > `e_book_backend_ogo_get_supported_fields': > > e-book-backend-ogo.c:251: error: incompatible type for argument 3 of > > `e_data_book_respond_get_supported_fields' > > e-book-backend-ogo.c:251: error: too few arguments to function > > `e_data_book_respond_get_supported_fields' > > e-book-backend-ogo.c: In function `e_book_backend_ogo_remove': > > e-book-backend-ogo.c:288: error: too few arguments to function > > `e_data_book_respond_remove' > > e-book-backend-ogo.c: In function `e_book_backend_ogo_class_init': > > e-book-backend-ogo.c:362: warning: assignment from incompatible pointer > > type > > e-book-backend-ogo.c:363: warning: assignment from incompatible pointer > > type > > e-book-backend-ogo.c:364: warning: assignment from incompatible pointer > > type > > e-book-backend-ogo.c:365: warning: assignment from incompatible pointer > > type > > e-book-backend-ogo.c:366: warning: assignment from incompatible pointer > > type > > e-book-backend-ogo.c:369: warning: assignment from incompatible pointer > > type > > e-book-backend-ogo.c:370: warning: assignment from incompatible pointer > > type > > e-book-backend-ogo.c:371: warning: assignment from incompatible pointer > > type > > e-book-backend-ogo.c:372: warning: assignment from incompatible pointer > > type > > e-book-backend-ogo.c:373: warning: assignment from incompatible pointer > > type > > make[4]: *** [e-book-backend-ogo.lo] Error 1 > > make[4]: Leaving directory > > `/home/bflong/build/evolution-ogo-0.0.3/addressbook/backends/ogo' > > make[3]: *** [all-recursive] Error 1 > > make[3]: Leaving directory > > `/home/bflong/build/evolution-ogo-0.0.3/addressbook/backends' > > make[2]: *** [all-recursive] Error 1 > > make[2]: Leaving directory > > `/home/bflong/build/evolution-ogo-0.0.3/addressbook' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/home/bflong/build/evolution-ogo-0.0.3' > > make: *** [all] Error 2 > >=20 > > --=20 > > Benjamin Long > > bflong@longbros.com > >=20 Thanks! I got the connector compiled and installed with evo 2.0. I can now work with my contacts, but there is no calendar. Is this something that is not implemented yet or did I do something wrong? --=20 Benjamin Long bflong@longbros.com From evolution@opengroupware.org Fri Oct 8 15:21:18 2004 From: evolution@opengroupware.org (Benjamin Long) Date: Fri, 08 Oct 2004 10:21:18 -0400 Subject: [OGo-Evolution] Building Evolution Connector In-Reply-To: <1097244695.8857.2.camel@localhost.localdomain> References: <1097181499.30159.4.camel@localhost.localdomain> <1097225787.12957.5.camel@localhost> <1097244695.8857.2.camel@localhost.localdomain> Message-ID: <1097245278.9216.0.camel@localhost.localdomain> On Fri, 2004-10-08 at 10:11 -0400, Benjamin Long wrote:=20 > On Fri, 2004-10-08 at 10:56 +0200, Jean-Pascal Robiez wrote: > > hello, > >=20 > > you need to patch e-book-backend-ogo.c to use this version of evolution= , > > all backend funtion have to pass the opid parameter. I don't have acces= s > > to cvs now so I can't make a diff but I join you the version of this > > file I use. > >=20 > > hope this helps, > >=20 > > JP > >=20 > >=20 > >=20 > > Le jeudi 07 octobre 2004 =E0 16:38 -0400, Benjamin Long a =E9crit : > > > I'm trying to build the connector for evolution. Reading the archives > > > tells me that I am running into the same problem as someone else, cau= sed > > > by the changes in evo version 2.0. Any help with this would be greatl= y > > > appreciated as I'm working on a rollout. Here's the end of my build l= og: > > > =20 > > > --=20 > > > Benjamin Long > > > bflong@longbros.com > > >=20 >=20 > Thanks! I got the connector compiled and installed with evo 2.0. I can > now work with my contacts, but there is no calendar. Is this something > that is not implemented yet or did I do something wrong? >=20 Sorry, I spoke too soon. I can *see* my contacts, but I can't change any of them, nor can I add any new ones. Is this expected or did I fudge something up? --=20 Benjamin Long bflong@longbros.com From evolution@opengroupware.org Fri Oct 8 16:16:41 2004 From: evolution@opengroupware.org (David Stanaway) Date: Fri, 08 Oct 2004 10:16:41 -0500 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <1097228268.2640.0.camel@dhcp246> References: <1097228268.2640.0.camel@dhcp246> Message-ID: <1097248601.14906.9.camel@david.dialmex.net> Hi Erik, Congratulations on the release. I am trying this out with a possibly dated zidestore 1.1.999cvs2004 (debian experimental package) and ximian-connector 2.0.1 I thought that I was not getting anywhere, and was trying to get some screenshots together, but meanwhile I did a evolution --force-shutdown then after that, all was good. What worked was to create an exchange mail account. I didn't have any luck with the /usr/bin/ximian-connector-setup-2.0 wizard. Are there any plans for mail integration as well? I see folders in the Mail view under Personal Folders, but they all give an error when I view them. The folders are: Groups {all intranet, news editors}, Projects, Trash It doesn't make a lot of sense to me to proxy the imap server via ex2ogo and ogo even if it was possible, but it might to someone else. -- David Stanaway From evolution@opengroupware.org Fri Oct 8 16:26:05 2004 From: evolution@opengroupware.org (Helge Hess) Date: Fri, 8 Oct 2004 17:26:05 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <1097248601.14906.9.camel@david.dialmex.net> References: <1097228268.2640.0.camel@dhcp246> <1097248601.14906.9.camel@david.dialmex.net> Message-ID: <5EE65316-193E-11D9-958E-000D93C1A604@opengroupware.org> On Oct 8, 2004, at 17:16, David Stanaway wrote: > It doesn't make a lot of sense to me to proxy the imap server via > ex2ogo > and ogo even if it was possible, but it might to someone else. ZideStore 1.5 will provide an WebDAV/HTTPmail to IMAP4 gateway. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Tue Oct 19 14:52:51 2004 From: evolution@opengroupware.org (Helge Hess) Date: Tue, 19 Oct 2004 15:52:51 +0200 Subject: [OGo-Evolution] Re: Evo 2.0 In-Reply-To: <1098193659.15968.28.camel@dhcp246> References: <603F744B-1EC5-11D9-88E6-000D93C1A604@skyrix.com> <41701A61.9090909@toltech.nl> <7B2624CE-20E0-11D9-A777-000D93C1A604@skyrix.com> <1098091062.16042.21.camel@dhcp246> <9659FB50-20E6-11D9-A777-000D93C1A604@opengroupware.org> <1098104451.16048.44.camel@dhcp246> <1098193659.15968.28.camel@dhcp246> Message-ID: <2B3B14F4-21D6-11D9-94D8-000D93C1A604@opengroupware.org> Hi Erik, moved discussion to evolution list, might be interesting for other people ;-) On Oct 19, 2004, at 15:47, Erik Romijn wrote: > The current way tasks are implemented is: fetch the names from the > PROPFIND and do a GET on each task item. The Connector accesses Exchange that way? (its not an OGo issue, right?) Maybe Dan can explain why no BPROPFIND is used for tasks. What does the GET return? I suppose an iCal VTODO wrapped in a MIME message? > This is done because we could > not find a way to make zidestore return all the needed data for all the > tasks in a single request. I could probably create a method which returns all tasks in a single call. What format would you prefer? > Ofcourse this is very ugly and very slow. > The slowness can be 'prevented' with a caching system. Yes, the caching system is a good idea in any way, but as mentioned it really belongs into the Connector ;-) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Tue Oct 19 15:06:51 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Tue, 19 Oct 2004 16:06:51 +0200 Subject: [OGo-Evolution] Re: Evo 2.0 In-Reply-To: <2B3B14F4-21D6-11D9-94D8-000D93C1A604@opengroupware.org> References: <603F744B-1EC5-11D9-88E6-000D93C1A604@skyrix.com> <41701A61.9090909@toltech.nl> <7B2624CE-20E0-11D9-A777-000D93C1A604@skyrix.com> <1098091062.16042.21.camel@dhcp246> <9659FB50-20E6-11D9-A777-000D93C1A604@opengroupware.org> <1098104451.16048.44.camel@dhcp246> <1098193659.15968.28.camel@dhcp246> <2B3B14F4-21D6-11D9-94D8-000D93C1A604@opengroupware.org> Message-ID: <1098194811.15968.38.camel@dhcp246> Hi Helge, On Tue, 2004-10-19 at 15:52, Helge Hess wrote: > > The current way tasks are implemented is: fetch the names from the > > PROPFIND and do a GET on each task item. > > The Connector accesses Exchange that way? (its not an OGo issue, > right?) Maybe Dan can explain why no BPROPFIND is used for tasks. > No. The connector does a BPROPFIND, but that does not seem to be supported by ZideStore. I may have overlooked something there though. > What does the GET return? I suppose an iCal VTODO wrapped in a MIME > message? If I remember correctly it does. I can't check it right now. The format the connector expects is XML, so ex2ogo builds up the XML data out of the VTODO's. > > This is done because we could > > not find a way to make zidestore return all the needed data for all the > > tasks in a single request. > I could probably create a method which returns all tasks in a single > call. What format would you prefer? An XML format like the connector expects would be the most convenient, as that would make ZideStore and the connector compatible in that part without ex2ogo being needed to mangle data. > > > Ofcourse this is very ugly and very slow. > > The slowness can be 'prevented' with a caching system. > Yes, the caching system is a good idea in any way, but as mentioned it > really belongs into the Connector ;-) I agree on that. But this product is also something that our company needs as soon as possible - if caching with zidestore and the connector will take some time before it is implemented it would be more interesting for us to implement something in ex2ogo for it too. We would have to keep in mind that ex2ogo is more meant like a proof of concept, which should become useless when the connector and zidestore achieve compatibility with each other. From evolution@opengroupware.org Tue Oct 19 14:40:42 2004 From: evolution@opengroupware.org (Helge Hess) Date: Tue, 19 Oct 2004 15:40:42 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <1097228268.2640.0.camel@dhcp246> References: <1097228268.2640.0.camel@dhcp246> Message-ID: <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> Hi there, small update. Thanks to Erik's work I was able to fix ZideStore to provide at least minimal Evo Connector 2.0.2 connectivity. That is, you can now properly login at ZideStore and even see some data. Currently Connector crashes when a task folder is selected (we'll find out why ;-) Of course it still has loads of issues, but I think together with the Perl work by Erik and the excellent Connector documentation by Dan Winship we can make it ;-) I currently have the impression that this might be a pragmatic way to go: 1) try to get most things working with Connector 2) fork & strip down Connector to what ZideStore provides 3) add ZideStore/OGo specific enhancements / optimisations Greets, Helge On Oct 8, 2004, at 11:37, Erik Romijn wrote: > the last month I have been working for my company on the perl daemon I > proposed earlier on this list. We now have basic read only calendar and > contact support for Evolution<->OGo. -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Tue Oct 19 15:58:14 2004 From: evolution@opengroupware.org (Helge Hess) Date: Tue, 19 Oct 2004 16:58:14 +0200 Subject: [OGo-Evolution] Re: Evo 2.0 In-Reply-To: <1098194811.15968.38.camel@dhcp246> References: <603F744B-1EC5-11D9-88E6-000D93C1A604@skyrix.com> <41701A61.9090909@toltech.nl> <7B2624CE-20E0-11D9-A777-000D93C1A604@skyrix.com> <1098091062.16042.21.camel@dhcp246> <9659FB50-20E6-11D9-A777-000D93C1A604@opengroupware.org> <1098104451.16048.44.camel@dhcp246> <1098193659.15968.28.camel@dhcp246> <2B3B14F4-21D6-11D9-94D8-000D93C1A604@opengroupware.org> <1098194811.15968.38.camel@dhcp246> Message-ID: <4D4FF528-21DF-11D9-94D8-000D93C1A604@opengroupware.org> On Oct 19, 2004, at 16:06, Erik Romijn wrote: >> The Connector accesses Exchange that way? (its not an OGo issue, >> right?) Maybe Dan can explain why no BPROPFIND is used for tasks. > No. The connector does a BPROPFIND, but that does not seem to be > supported by ZideStore. I may have overlooked something there though. OK, so we just need to implement that BPROPFIND. I try to look into that. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Tue Oct 19 16:05:36 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Tue, 19 Oct 2004 17:05:36 +0200 Subject: [OGo-Evolution] Re: Evo 2.0 In-Reply-To: <4D4FF528-21DF-11D9-94D8-000D93C1A604@opengroupware.org> References: <603F744B-1EC5-11D9-88E6-000D93C1A604@skyrix.com> <41701A61.9090909@toltech.nl> <7B2624CE-20E0-11D9-A777-000D93C1A604@skyrix.com> <1098091062.16042.21.camel@dhcp246> <9659FB50-20E6-11D9-A777-000D93C1A604@opengroupware.org> <1098104451.16048.44.camel@dhcp246> <1098193659.15968.28.camel@dhcp246> <2B3B14F4-21D6-11D9-94D8-000D93C1A604@opengroupware.org> <1098194811.15968.38.camel@dhcp246> <4D4FF528-21DF-11D9-94D8-000D93C1A604@opengroupware.org> Message-ID: <1098198335.15968.44.camel@dhcp246> Hi, On Tue, 2004-10-19 at 16:58, Helge Hess wrote: > OK, so we just need to implement that BPROPFIND. I try to look into > that. Sorry, I was mistaken. It does a SEARCH, not a BPROPFIND. Greetings, Erik From evolution@opengroupware.org Tue Oct 19 16:06:30 2004 From: evolution@opengroupware.org (Helge Hess) Date: Tue, 19 Oct 2004 17:06:30 +0200 Subject: [OGo-Evolution] Re: Evo 2.0 In-Reply-To: <1098198335.15968.44.camel@dhcp246> References: <603F744B-1EC5-11D9-88E6-000D93C1A604@skyrix.com> <41701A61.9090909@toltech.nl> <7B2624CE-20E0-11D9-A777-000D93C1A604@skyrix.com> <1098091062.16042.21.camel@dhcp246> <9659FB50-20E6-11D9-A777-000D93C1A604@opengroupware.org> <1098104451.16048.44.camel@dhcp246> <1098193659.15968.28.camel@dhcp246> <2B3B14F4-21D6-11D9-94D8-000D93C1A604@opengroupware.org> <1098194811.15968.38.camel@dhcp246> <4D4FF528-21DF-11D9-94D8-000D93C1A604@opengroupware.org> <1098198335.15968.44.camel@dhcp246> Message-ID: <74FC0A84-21E0-11D9-94D8-000D93C1A604@opengroupware.org> On Oct 19, 2004, at 17:05, Erik Romijn wrote: > It does a SEARCH, not a BPROPFIND. Same thing ;-) The important part is that the Connector already uses a bulk query which is good. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Tue Oct 19 22:46:23 2004 From: evolution@opengroupware.org (Jon Lawrence) Date: Tue, 19 Oct 2004 22:46:23 +0100 Subject: [OGo-Evolution] Evo OpenGroupware with ximian connector Message-ID: <1098222383.22114.16.camel@localhost> Hi all. I've just come across the OpenGroupware software. I'm trying to connect Evolution to my OpenGroupware server. Versions are: Evolution version 1.4.5 ximian connector 1.4.7.2 I'm not sure if I've configured the account correctly on either the groupware server or Evolution. I can log in fine via apache to OpenGroupware, is there anything specific to do to allow Evolution to log in. In Evolution, I've setup the following: Receiving Mail: Exchange Server: Windows Username: Use SSL: Never Authentication type: Plaintext Password. Receiving Options: Global Address List/Active Directory: Mailbox name: OWA path: /OpenGroupware Public Folder server: If I look at the apache logs during an attempted connection, I see hundreds of the following: - - [19/Oct/2004:22:27:17 +0100] "SEARCH /OpenGroupware/jon/ HTTP/1.1" 200 4982 "-" "Evolution/1.4.5" If anyone could offer any pointers please do. One thing I'm not sure of is whether I've got zidestore running - how can I check ? TIA Jon Lawrence From evolution@opengroupware.org Tue Oct 19 23:16:43 2004 From: evolution@opengroupware.org (Jon Lawrence) Date: Tue, 19 Oct 2004 23:16:43 +0100 Subject: [OGo-Evolution] Evo OpenGroupware with ximian connector In-Reply-To: <1098222383.22114.16.camel@localhost> References: <1098222383.22114.16.camel@localhost> Message-ID: <1098224203.22550.2.camel@localhost> On Tue, 2004-10-19 at 22:46, Jon Lawrence wrote: > Hi all. > I've just come across the OpenGroupware software. > I'm trying to connect Evolution to my OpenGroupware server. > Versions are: > Evolution version 1.4.5 > ximian connector 1.4.7.2 > > I'm not sure if I've configured the account correctly on either the > groupware server or Evolution. > I can log in fine via apache to OpenGroupware, is there anything > specific to do to allow Evolution to log in. > In Evolution, I've setup the following: > Receiving Mail: > Exchange Server: > Windows Username: > Use SSL: Never > Authentication type: Plaintext Password. > > Receiving Options: > Global Address List/Active Directory: > Mailbox name: > OWA path: /OpenGroupware > Public Folder server: > > > If I look at the apache logs during an attempted connection, I see > hundreds of the following: > - - [19/Oct/2004:22:27:17 +0100] "SEARCH /OpenGroupware/jon/ > HTTP/1.1" 200 4982 "-" "Evolution/1.4.5" > > If anyone could offer any pointers please do. > > One thing I'm not sure of is whether I've got zidestore running - how > can I check ? Okay, I know, bad form to reply to yourself :) I found that by adapting the info on setting up with RH9, I've managed to get it working. I needed to configure and run zidestore - I'd missed that bit completely. In evolution, I needed to have OWA path set as /zidestore/so Heypresto everything seems to work now. Regards, Jon From evolution@opengroupware.org Wed Oct 20 06:49:16 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Wed, 20 Oct 2004 07:49:16 +0200 Subject: [OGo-Evolution] Evo OpenGroupware with ximian connector In-Reply-To: <1098224203.22550.2.camel@localhost> References: <1098222383.22114.16.camel@localhost> <1098224203.22550.2.camel@localhost> Message-ID: <4175FC5C.5030006@toltech.nl> Hi Jon, Jon Lawrence wrote: >>Hi all. >>I've just come across the OpenGroupware software. >>I'm trying to connect Evolution to my OpenGroupware server. >>Versions are: >>Evolution version 1.4.5 >>ximian connector 1.4.7.2 >> > I found that by adapting the info on setting up with RH9, I've managed > to get it working. You are saying that you have a working setup for evolution<->opengroupware with the 1.4 connector and evolution? As far as I know ZideStore was still (partially) incompatible with the 1.3 connector. Greetings, Erik Romijn From evolution@opengroupware.org Wed Oct 20 08:26:55 2004 From: evolution@opengroupware.org (Jon Lawrence) Date: Wed, 20 Oct 2004 08:26:55 +0100 Subject: [OGo-Evolution] Evo OpenGroupware with ximian connector In-Reply-To: <4175FC5C.5030006@toltech.nl> References: <1098222383.22114.16.camel@localhost> <1098224203.22550.2.camel@localhost> <4175FC5C.5030006@toltech.nl> Message-ID: <200410200826.55905.jon@lawrence.org.uk> > > You are saying that you have a working setup for > evolution<->opengroupware with the 1.4 connector and evolution? > As far as I know ZideStore was still (partially) incompatible with the > 1.3 connector. > > Greetings, > Erik Romijn Not sure if it's working correctly yet. It's definitely connecting to the server - which is more than it did originally. Jon From evolution@opengroupware.org Wed Oct 20 09:04:03 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Wed, 20 Oct 2004 10:04:03 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> Message-ID: <1098259442.22841.6.camel@dhcp-192-168-0-246.localnet> On Tue, 2004-10-19 at 15:40, Helge Hess wrote: > Thanks to Erik's work I was able to fix ZideStore to provide at least > minimal Evo Connector 2.0.2 connectivity. That is, you can now properly > login at ZideStore and even see some data. What kind of data can you see? I assume you are referring to the contacts? Or do more things work? Greetings, Erik Romijn From evolution@opengroupware.org Wed Oct 20 11:39:49 2004 From: evolution@opengroupware.org (Jon Lawrence) Date: Wed, 20 Oct 2004 11:39:49 +0100 Subject: [OGo-Evolution] Evo OpenGroupware with ximian connector In-Reply-To: <200410200826.55905.jon@lawrence.org.uk> References: <1098222383.22114.16.camel@localhost> <4175FC5C.5030006@toltech.nl> <200410200826.55905.jon@lawrence.org.uk> Message-ID: <200410201139.49326.jon@lawrence.org.uk> On Wednesday 20 October 2004 08:26, Jon Lawrence wrote: > > You are saying that you have a working setup for > > evolution<->opengroupware with the 1.4 connector and evolution? > > As far as I know ZideStore was still (partially) incompatible with the > > 1.3 connector. > > > > Greetings, > > Erik Romijn > > Not sure if it's working correctly yet. > It's definitely connecting to the server - which is more than it did > originally. > To update. No it doesn't work. The connector logs into the server correctly, but never gets any data back. I can see in my logs that there has supposably been 1 apts fetched but it's never visable in Evo. I'm going to try the ogo connector and see if that does any better :) Jon From evolution@opengroupware.org Wed Oct 20 12:22:10 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Wed, 20 Oct 2004 13:22:10 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> Message-ID: <1098271330.10064.12.camel@s003018577431> On Tue, 2004-10-19 at 15:40 +0200, Helge Hess wrote: > Thanks to Erik's work I was able to fix ZideStore to provide at least > minimal Evo Connector 2.0.2 connectivity. That is, you can now properly > login at ZideStore and even see some data. Is this ZideStore version also already available in trunk? I have just tested with the ex2ogo daemon and the latest trunk packages for suse that were available yesterday (r256.7). Testing with Evolution and Connector 2.0.1 basic writing support for calendar items seems to work. Without having looked into it any further, recurrency and alarms are not working. I have looked into read support for recurrency for evo<->ogo and I noticed that OGo sets both a few properties in the item and ZideStore returns another appointment item for each occurrence of the appointment. With ex2ogo for reading recurrency is not handled, ZideStore just tells it every occurrence of the item. Does the client really have to insert all the different occurrences of the item or does ZideStore just generate this when requested? In the latter case it should be not too hard to let Evo and ZideStore understand each others data related to recurrency. Task and Contact writing will be a bit harder, as the connector uses the PROPPATCH request which is not implemented by ZideStore. I haven't looked into what exactly the request contains. In ex2ogo this should probably be handled by mangling it into a PUT if possible until ZideStore understands the PROPPATCH. Greetings, Erik Romijn From evolution@opengroupware.org Wed Oct 20 12:36:21 2004 From: evolution@opengroupware.org (Jon Lawrence) Date: Wed, 20 Oct 2004 12:36:21 +0100 Subject: [OGo-Evolution] evo-ogo Message-ID: <1098272181.26005.6.camel@localhost> Hi all, I've pulled the evolution-ogo from svn. It appears to have configured and compiled fine. Installing it installed the following files: /usr/libexec/evolution/1.4/evolution-ogo-storage /usr/local/lib/bonobo/servers/GNOME_Evolution_OGO_Storage.server /usr/local/share/locale/cy/LC_MESSAGES/evolution-ogo-1.0.mo /usr/local/share/locale/de/LC_MESSAGES/evolution-ogo-1.0.mo /usr/local/share/locale/sv/LC_MESSAGES/evolution-ogo-1.0.mo + some docs. I've read the README, which talks about using gconftool-2 t configure the connector. I did what it says and got no errors returned. But I can't see any changes in Evo itself. So I suppose my question is how do I create an account using the evolution-ogo plugin ? TIA, Jon Lawrence From evolution@opengroupware.org Wed Oct 20 12:54:25 2004 From: evolution@opengroupware.org (Adam Tauno Williams) Date: Wed, 20 Oct 2004 07:54:25 -0400 Subject: [OGo-Evolution] evo-ogo In-Reply-To: <1098272181.26005.6.camel@localhost> References: <1098272181.26005.6.camel@localhost> Message-ID: <1098273265.4740.37.camel@estate3.whitemice.org> > I've pulled the evolution-ogo from svn. > It appears to have configured and compiled fine. > Installing it installed the following files: > /usr/libexec/evolution/1.4/evolution-ogo-storage > /usr/local/lib/bonobo/servers/GNOME_Evolution_OGO_Storage.server This path is probably wrong. You need to put this file where your other *.server files are (most likely not in /usr/local) From evolution@opengroupware.org Wed Oct 20 18:05:04 2004 From: evolution@opengroupware.org (Jon Lawrence) Date: Wed, 20 Oct 2004 18:05:04 +0100 Subject: [OGo-Evolution] evo-ogo In-Reply-To: <1098273265.4740.37.camel@estate3.whitemice.org> References: <1098272181.26005.6.camel@localhost> <1098273265.4740.37.camel@estate3.whitemice.org> Message-ID: <200410201805.04451.jon@lawrence.org.uk> On Wednesday 20 October 2004 12:54, Adam Tauno Williams wrote: > > I've pulled the evolution-ogo from svn. > > It appears to have configured and compiled fine. > > Installing it installed the following files: > > /usr/libexec/evolution/1.4/evolution-ogo-storage > > /usr/local/lib/bonobo/servers/GNOME_Evolution_OGO_Storage.server > > This path is probably wrong. You need to put this file where your other > *.server files are (most likely not in /usr/local) That's sorted it. Thanks, now to play and see how it goes. Thanks, Jon. From evolution@opengroupware.org Wed Oct 20 23:49:11 2004 From: evolution@opengroupware.org (Helge Hess) Date: Thu, 21 Oct 2004 00:49:11 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <1098271330.10064.12.camel@s003018577431> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> Message-ID: <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> On Oct 20, 2004, at 13:22, Erik Romijn wrote: > On Tue, 2004-10-19 at 15:40 +0200, Helge Hess wrote: >> Thanks to Erik's work I was able to fix ZideStore to provide at least >> minimal Evo Connector 2.0.2 connectivity. That is, you can now >> properly >> login at ZideStore and even see some data. > Is this ZideStore version also already available in trunk? Yes. > Without having looked into it any further, recurrency and alarms are > not > working. I don't think that recurrency is supposed to work atm. AFAIK the old iCalSaxDriver could not properly parse it. Now I don't know the current situation wrt recurrencies, since we recently moved to the new versitSaxDriver (written by Max Berger and ZNeK). > I have looked into read support for recurrency for evo<->ogo and I > noticed that OGo sets both a few properties in the item and ZideStore > returns another appointment item for each occurrence of the > appointment. Yes. iCal recurrencies do not match OGo recurrencies. In OGo recurrencies are individual (but connected) database items after creation while in iCalendar recurrencies are represented by a so called "recurrence rule" which is "calculated". So when ZideStore receives an iCal PUT of a recurrence, it is supposed to create an OGo recurrence sequence. On the next query OGo will return all items as individual events (because its close to impossible to reconstruct a rrule from the events). Note: I'm not sure whether this already works properly, I guess not. > Task and Contact writing will be a bit harder, as the connector uses > the > PROPPATCH request which is not implemented by ZideStore. Well, it is implemented, but it needs to get fixed for Evo 2.x requirements. We'll do this. > I haven't looked into what exactly the request contains. In ex2ogo > this should > probably be handled by mangling it into a PUT if possible until > ZideStore understands the PROPPATCH. Actually contact modification AFAIK only works with PROPPATCH (and not with vCard PUT!) in current ZideStore. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Thu Oct 21 09:52:16 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Thu, 21 Oct 2004 10:52:16 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> Message-ID: <1098348736.15486.3.camel@s003018577431> On Thu, 2004-10-21 at 00:49 +0200, Helge Hess wrote: > > I haven't looked into what exactly the request contains. In ex2ogo > > this should > > probably be handled by mangling it into a PUT if possible until > > ZideStore understands the PROPPATCH. > > Actually contact modification AFAIK only works with PROPPATCH (and not > with vCard PUT!) in current ZideStore. With a PROPPATCH ZideStore returns a HTTP501 (method not implemented). I thought that meant that the request was not supported. If ZideStore already supports the PROPPATCH we would just have to find out what exactly has changed that makes ZideStore return a 501. An addition to the PUT's on calendar items: Evo returns an error after PUTting the item although it is added correctly. Probably ZideStore's response would have to be modified to make Evo believe it was succesful. Greetings, Erik Romijn From evolution@opengroupware.org Thu Oct 21 10:49:10 2004 From: evolution@opengroupware.org (Helge Hess) Date: Thu, 21 Oct 2004 11:49:10 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <1098348736.15486.3.camel@s003018577431> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> Message-ID: <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> On Oct 21, 2004, at 10:52, Erik Romijn wrote: > With a PROPPATCH ZideStore returns a HTTP501 (method not implemented). > I > thought that meant that the request was not supported. Yes, I suppose this would be correct HTTP ;-) ZideStore currently returns 501 whenever it encounters a requests which it basically understands but can't handle. If there is a better response code for this case, let me know. > If ZideStore already supports the PROPPATCH we would just have to find > out what exactly has changed that makes ZideStore return a 501. Exactly. BTW: Actually what URL supports what request is determined by the so called "SoObjects" (which are bound to the URL lookup path and can be found in ZideStore/SoObjects/ in the source). So while a SoContactFolder might support PROPPATCH this doesn't imply that a SoCalendarFolder does as well. Those folders (and contained objects) are responsible for mapping some form of HTTP data to the internal OGo Logic calls. > An addition to the PUT's on calendar items: Evo returns an error after > PUTting the item although it is added correctly. Probably ZideStore's > response would have to be modified to make Evo believe it was > succesful. What does it return at the moment? If its 200 (Ok), one might try 201 (Created). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Thu Oct 21 11:22:32 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Thu, 21 Oct 2004 12:22:32 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> Message-ID: <1098354152.15486.15.camel@s003018577431> On Thu, 2004-10-21 at 11:49 +0200, Helge Hess wrote: > On Oct 21, 2004, at 10:52, Erik Romijn wrote: > > With a PROPPATCH ZideStore returns a HTTP501 (method not implemented). > > I thought that meant that the request was not supported. > > Yes, I suppose this would be correct HTTP ;-) > > ZideStore currently returns 501 whenever it encounters a requests which > it basically understands but can't handle. If there is a better > response code for this case, let me know. Maybe a 405 would be appropriate. >From HTTP RFC: ---snip--- 405 Method Not Allowed The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource. ---snap--- > > An addition to the PUT's on calendar items: Evo returns an error after > > PUTting the item although it is added correctly. Probably ZideStore's > > response would have to be modified to make Evo believe it was > > succesful. > > What does it return at the moment? If its 200 (Ok), one might try 201 > (Created). Changing it to a 201 works. Evo now also displays the item after it has been added, without evo thinking it was successful a restart was required to display it. Implemented in ex2ogo-0.1.1 (although it's not much special): http://oracle.toltech.nl/~erik/ex2ogo-0.1.1.pl Shouldn't be too hard to implement in ZideStore I guess. On the required restart of evo: as far as I understood from the connector people the connector uses SUBSCRIBE to make the server tell the connector when data is updated. In it's current form it doesn't seem to work, haven't looked into it very far. I think I'll start taking a look at compatibility between Evo's alarm and OGo's reminder. It guess it should be possible to convert between the two. Greetings, Erik Romijn From evolution@opengroupware.org Thu Oct 21 11:59:04 2004 From: evolution@opengroupware.org (Helge Hess) Date: Thu, 21 Oct 2004 12:59:04 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <1098354152.15486.15.camel@s003018577431> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098354152.15486.15.camel@s003018577431> Message-ID: <38E0CCD6-2350-11D9-8364-000D93C1A604@opengroupware.org> On Oct 21, 2004, at 12:22, Erik Romijn wrote: >> ZideStore currently returns 501 whenever it encounters a requests >> which >> it basically understands but can't handle. If there is a better >> response code for this case, let me know. > Maybe a 405 would be appropriate. I think its pretty much the same like 501. > Changing it to a 201 works. Evo now also displays the item after it has > been added, without evo thinking it was successful a restart was > required to display it. ... > Shouldn't be too hard to implement in ZideStore I guess. Should be in trunk r272. > On the required restart of evo: as far as I understood from the > connector people the connector uses SUBSCRIBE to make the server tell > the connector when data is updated. In it's current form it doesn't > seem > to work, haven't looked into it very far. Well, SOPE supports SUBSCRIBE and maintains a subscription list (sope-appserver/NGObjWeb/WebDAV/SoSubscriptionManager.[hm]). But ZideStore never sends notifications. I'm not yet sure what is the best time to send which subscriptions. I suppose ZideStore should send refresh notifications every n-minutes (because it can't know whether other services changed something in the store). In addition the current subscription manager keeps subscriptions in RAM and therefore doesn't work with multiple ZideStore instances. In short: a proper/complete implementation of subscribe is a _lot_ of work. I don't think its worth the effort. Rather post notifications at "clever" times ;-) > I think I'll start taking a look at compatibility between Evo's alarm > and OGo's reminder. It guess it should be possible to convert between > the two. OK, great. I think for Outlook we just store the alarm in a separate database field. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Thu Oct 21 12:17:31 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Thu, 21 Oct 2004 13:17:31 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <38E0CCD6-2350-11D9-8364-000D93C1A604@opengroupware.org> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098354152.15486.15.camel@s003018577431> <38E0CCD6-2350-11D9-8364-000D93C1A604@opengroupware.org> Message-ID: <1098357451.15486.23.camel@s003018577431> On Thu, 2004-10-21 at 12:59 +0200, Helge Hess wrote: > On Oct 21, 2004, at 12:22, Erik Romijn wrote: > >> ZideStore currently returns 501 whenever it encounters a requests > >> which > >> it basically understands but can't handle. If there is a better > >> response code for this case, let me know. > > Maybe a 405 would be appropriate. > > I think its pretty much the same like 501. Yes, but maybe it would be useful to use different responses for an unknown request and a known request with unprocessable data. > In short: a proper/complete implementation of subscribe is a _lot_ of > work. I don't think its worth the effort. Rather post notifications at > "clever" times ;-) We could just make ZideStore send a notification at regular intervals. This would cause evo to refresh it's data; if no new data is available that won't matter. It would not be very pretty, but at least it would work ;-) > > I think I'll start taking a look at compatibility between Evo's alarm > > and OGo's reminder. It guess it should be possible to convert between > > the two. > > OK, great. I think for Outlook we just store the alarm in a separate > database field. You mean for ZideLook? I think it would be nice if OGo reminder and Evo alarm were connected to each other and not in seperated fields. Greetings, Erik From evolution@opengroupware.org Thu Oct 21 12:20:23 2004 From: evolution@opengroupware.org (Helge Hess) Date: Thu, 21 Oct 2004 13:20:23 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <1098357451.15486.23.camel@s003018577431> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098354152.15486.15.camel@s003018577431> <38E0CCD6-2350-11D9-8364-000D93C1A604@opengroupware.org> <1098357451.15486.23.camel@s003018577431> Message-ID: <339281A4-2353-11D9-8364-000D93C1A604@opengroupware.org> On Oct 21, 2004, at 13:17, Erik Romijn wrote: > We could just make ZideStore send a notification at regular intervals. > This would cause evo to refresh it's data; if no new data is available > that won't matter. It would not be very pretty, but at least it would > work ;-) Yes. >>> I think I'll start taking a look at compatibility between Evo's alarm >>> and OGo's reminder. It guess it should be possible to convert between >>> the two. >> OK, great. I think for Outlook we just store the alarm in a separate >> database field. > You mean for ZideLook? Yes. > I think it would be nice if OGo reminder and Evo alarm were connected > to each other and not in seperated fields. I suppose that this would imply that OGo/skyaptnotify would need to support everything supported by iCalendar alarms. I suppose this would be quite a lot of work, but I didn't investigate. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Thu Oct 21 12:25:08 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Thu, 21 Oct 2004 13:25:08 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <339281A4-2353-11D9-8364-000D93C1A604@opengroupware.org> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098354152.15486.15.camel@s003018577431> <38E0CCD6-2350-11D9-8364-000D93C1A604@opengroupware.org> <1098357451.15486.23.camel@s003018577431> <339281A4-2353-11D9-8364-000D93C1A604@opengroupware.org> Message-ID: <1098357908.15484.27.camel@s003018577431> On Thu, 2004-10-21 at 13:20 +0200, Helge Hess wrote: > > I think it would be nice if OGo reminder and Evo alarm were connected > > to each other and not in seperated fields. > > I suppose that this would imply that OGo/skyaptnotify would need to > support everything supported by iCalendar alarms. I suppose this would > be quite a lot of work, but I didn't investigate. Now that I've taken a closer look at it, evo has much more possibilities than the OGo WebUI. I agree that would mean a lot of work. Maybe we could use a seperate field for Evo too? Greetings, Erik From evolution@opengroupware.org Thu Oct 21 12:35:15 2004 From: evolution@opengroupware.org (Helge Hess) Date: Thu, 21 Oct 2004 13:35:15 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <1098357908.15484.27.camel@s003018577431> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098354152.15486.15.camel@s003018577431> <38E0CCD6-2350-11D9-8364-000D93C1A604@opengroupware.org> <1098357451.15486.23.camel@s003018577431> <339281A4-2353-11D9-8364-000D93C1A604@opengroupware.org> <1098357908.15484.27.camel@s003018577431> Message-ID: <46FD7BA3-2355-11D9-8364-000D93C1A604@opengroupware.org> On Oct 21, 2004, at 13:25, Erik Romijn wrote: > Now that I've taken a closer look at it, evo has much more > possibilities > than the OGo WebUI. I agree that would mean a lot of work. > Maybe we could use a seperate field for Evo too? Just had a look. The "date" (appointment) table already has a column "evo_reminder" ;-) Not sure whether this is already used in ZideStore. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Thu Oct 21 14:10:21 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Thu, 21 Oct 2004 15:10:21 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> Message-ID: <1098364221.19196.6.camel@s003018577431> On Thu, 2004-10-21 at 11:49 +0200, Helge Hess wrote: > > If ZideStore already supports the PROPPATCH we would just have to find > > out what exactly has changed that makes ZideStore return a 501. > > Exactly. I'm now looking at the Contacts. It seems that the connector does use a PUT to send modifications to contacts. And even better, zidestore can already process that. Connector sends: --snip-- PUT /zidestore/public/Contacts/76770.EML HTTP/1.1 Authorization: Basic ZXJpazpFcjM0KjU= Content-Length: 294 Content-Type: message/rfc822 Host: localhost:1234 Translate: f User-Agent: Evolution/2.0.1 content-class: urn:content-classes:person Subject: ajkl hklj X-MS-Has-Attach: yes From: Salsa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Thu, 21 Oct 2004 15:00:41 +0200 Message-Id: <1098363641.19219.1.camel@s003018577431> Mime-Version: 1.0 --snap-- ZideStore replies to this with a regular HTTP 200 which evolution accepts. For inserting a new contact, the connector sends this: --snip-- PROPPATCH /zidestore/erik/Contacts/a.EML HTTP/1.1 Authorization: Basic ZXJpazpFcjM0KjU= Brief: t Content-Length: 808 Content-Type: text/xml Host: localhost:1234 If-None-Match: * User-Agent: Evolution/2.0.1 IPM.Contact16aa0a51200a --snap-- ZideStore replies this: --snip-- HTTP/1.1 501 Method Not Implemented Connection: close Content-Length: 211 Date: Thu, 21 Oct 2004 12:55:10 GMT Server: Microsoft-IIS/5.0 content-type: text/html; charset="iso-8859-1"

An error occured during object publishing

object creation not available on this object

--snap-- Actually I have no idea where to look for the source of this error. Difficulty here is that I don't have any other examples from which I can read the correct format of the request. Do you see anything that is likely not to be accepted by ZideStore? Greetings, Erik From evolution@opengroupware.org Thu Oct 21 15:55:41 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Thu, 21 Oct 2004 16:55:41 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <1098364221.19196.6.camel@s003018577431> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098364221.19196.6.camel@s003018577431> Message-ID: <1098370541.19200.9.camel@s003018577431> On Thu, 2004-10-21 at 15:10 +0200, Erik Romijn wrote: > I'm now looking at the Contacts. > > It seems that the connector does use a PUT to send modifications to > contacts. And even better, zidestore can already process that. More good news: ZideStore seems to support the basics of adding and modifying tasks. Should do some more testing on it to see what exactly is and is not working properly. It seems there was lots of good work done by Helge on Opengroupware1.0a, as none of these things seem to work on the latest OGo stable release. Greetings, Erik From evolution@opengroupware.org Thu Oct 21 15:56:46 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Thu, 21 Oct 2004 16:56:46 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <1098364221.19196.6.camel@s003018577431> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098364221.19196.6.camel@s003018577431> Message-ID: <1098370606.19196.11.camel@s003018577431> On Thu, 2004-10-21 at 15:10 +0200, Erik Romijn wrote: > I'm now looking at the Contacts. > > It seems that the connector does use a PUT to send modifications to > contacts. And even better, zidestore can already process that. More good news: ZideStore seems to support the basics of adding and modifying tasks. Should do some more testing on it to see what exactly is and is not working properly. It seems there was lots of good work done by Helge on Opengroupware1.0a, as none of these things seem to work on the latest OGo stable release. Greetings, Erik From evolution@opengroupware.org Thu Oct 21 16:03:41 2004 From: evolution@opengroupware.org (Helge Hess) Date: Thu, 21 Oct 2004 17:03:41 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <1098364221.19196.6.camel@s003018577431> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098364221.19196.6.camel@s003018577431> Message-ID: <651E2BCB-2372-11D9-8364-000D93C1A604@opengroupware.org> On Oct 21, 2004, at 15:10, Erik Romijn wrote: > Actually I have no idea where to look for the source of this error. > Difficulty here is that I don't have any other examples from which I > can > read the correct format of the request. Do you see anything that is > likely not to be accepted by ZideStore? Yes, I need to look into this. For your script you could probably convert it to a PUT, not sure. First, I need to solve the crash with the task query (I can't start the connector anymore due to this issue ;-). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Thu Oct 21 16:32:36 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Thu, 21 Oct 2004 17:32:36 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <651E2BCB-2372-11D9-8364-000D93C1A604@opengroupware.org> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098364221.19196.6.camel@s003018577431> <651E2BCB-2372-11D9-8364-000D93C1A604@opengroupware.org> Message-ID: <1098372756.19196.15.camel@s003018577431> On Thu, 2004-10-21 at 17:03 +0200, Helge Hess wrote: > On Oct 21, 2004, at 15:10, Erik Romijn wrote: > > Actually I have no idea where to look for the source of this error. > > Difficulty here is that I don't have any other examples from which I > > can > > read the correct format of the request. Do you see anything that is > > likely not to be accepted by ZideStore? > > Yes, I need to look into this. For your script you could probably > convert it to a PUT, not sure. I will try and see if it works. > First, I need to solve the crash with the task query (I can't start the > connector anymore due to this issue ;-). What does it crash on? I assume you saw how ex2ogo handles the SEARCH on a task folder, I haven't noticed anything else that it could crash on. Greetings, Erik From evolution@opengroupware.org Thu Oct 21 16:32:36 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Thu, 21 Oct 2004 17:32:36 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <651E2BCB-2372-11D9-8364-000D93C1A604@opengroupware.org> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098364221.19196.6.camel@s003018577431> <651E2BCB-2372-11D9-8364-000D93C1A604@opengroupware.org> Message-ID: <1098372756.19196.15.camel@s003018577431> On Thu, 2004-10-21 at 17:03 +0200, Helge Hess wrote: > On Oct 21, 2004, at 15:10, Erik Romijn wrote: > > Actually I have no idea where to look for the source of this error. > > Difficulty here is that I don't have any other examples from which I > > can > > read the correct format of the request. Do you see anything that is > > likely not to be accepted by ZideStore? > > Yes, I need to look into this. For your script you could probably > convert it to a PUT, not sure. I will try and see if it works. > First, I need to solve the crash with the task query (I can't start the > connector anymore due to this issue ;-). What does it crash on? I assume you saw how ex2ogo handles the SEARCH on a task folder, I haven't noticed anything else that it could crash on. Greetings, Erik From evolution@opengroupware.org Thu Oct 21 16:41:20 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Thu, 21 Oct 2004 17:41:20 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <1098372756.19196.15.camel@s003018577431> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098364221.19196.6.camel@s003018577431> <651E2BCB-2372-11D9-8364-000D93C1A604@opengroupware.org> <1098372756.19196.15.camel@s003018577431> Message-ID: <1098373280.19192.17.camel@s003018577431> On Thu, 2004-10-21 at 17:32 +0200, Erik Romijn wrote: > [....] > What does it crash on? I assume you saw how ex2ogo handles the SEARCH on > a task folder, I haven't noticed anything else that it could crash on. > > Greetings, > Erik Sorry for having sent the same e-mail twice for two times, something must be messed up with my mailclient. Greetings, Erik From evolution@opengroupware.org Thu Oct 21 17:05:41 2004 From: evolution@opengroupware.org (Robert de Geus) Date: Thu, 21 Oct 2004 18:05:41 +0200 Subject: [OGo-Evolution] evo-ogo In-Reply-To: <200410201805.04451.jon@lawrence.org.uk> References: <1098272181.26005.6.camel@localhost> <1098273265.4740.37.camel@estate3.whitemice.org> <200410201805.04451.jon@lawrence.org.uk> Message-ID: <1098374741.4949.8.camel@000bdb18f9d2> Great news! After trying the stuff Erik wrote, we are able to create shared meetings in zidestore / opengroupware from evolution. You have to be careful not to use the free busy tab, but in Invitations you have to use the contacts button. By selecting a user from the user accounts, the meeting is entered in ogo as a calender item viewable by both users!! Cheers Robert On Wed, 2004-10-20 at 18:05 +0100, Jon Lawrence wrote: > On Wednesday 20 October 2004 12:54, Adam Tauno Williams wrote: > > > I've pulled the evolution-ogo from svn. > > > It appears to have configured and compiled fine. > > > Installing it installed the following files: > > > /usr/libexec/evolution/1.4/evolution-ogo-storage > > > /usr/local/lib/bonobo/servers/GNOME_Evolution_OGO_Storage.server > > > > This path is probably wrong. You need to put this file where your other > > *.server files are (most likely not in /usr/local) > > That's sorted it. Thanks, now to play and see how it goes. > > Thanks, > Jon. From evolution@opengroupware.org Thu Oct 21 17:09:13 2004 From: evolution@opengroupware.org (Helge Hess) Date: Thu, 21 Oct 2004 18:09:13 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <1098372756.19196.15.camel@s003018577431> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098364221.19196.6.camel@s003018577431> <651E2BCB-2372-11D9-8364-000D93C1A604@opengroupware.org> <1098372756.19196.15.camel@s003018577431> Message-ID: <8D162E5C-237B-11D9-8364-000D93C1A604@opengroupware.org> On Oct 21, 2004, at 17:32, Erik Romijn wrote: > What does it crash on? I assume you saw how ex2ogo handles the SEARCH > on > a task folder, I haven't noticed anything else that it could crash on. Hm, actually it works if I start Evolution "the usual way". But when I start the connector in the shell (in GDB), and then Evo, I still get a crash in: ---snip--- ** (evolution-exchange-storage:6887): CRITICAL **: file e2k-result.c: line 111 (prop_parse): assertion `node->ns != NULL' failed Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 32771 (LWP 6887)] 0x080951c3 in icaltime_to_e2k_time () (gdb) bt #0 0x080951c3 in icaltime_to_e2k_time () #1 0x0809574d in icaltime_to_e2k_time () #2 0x43db8bc5 in e_cal_backend_sync_open () from /usr/lib/libedata-cal.so.5 ---snap--- ---snip--- 192.168.0.111 - - [21/Oct/2004:18:05:16 GMT] "PROPFIND /zidestore/so/helge/Tasks/ HTTP/1.1" 401 0 0.003 - - 0 192.168.0.111 - - [21/Oct/2004:18:05:16 GMT] "PROPFIND /zidestore/so/helge/Tasks/ HTTP/1.1" 207 413 0.008 - - 0 Oct 21 18:05:16 ogo-zidestore-1.3 [6755]: |SxTaskFolder:Tasks| evolution query: davContentClass = 'urn:content-classes:task' 192.168.0.111 - - [21/Oct/2004:18:05:16 GMT] "SEARCH /zidestore/so/helge/Tasks/ HTTP/1.1" 207 3355 0.111 - - 0 192.168.0.111 - - [21/Oct/2004:18:07:00 GMT] "PROPFIND /zidestore/so/helge/NON_IPM_SUBTREE/ HTTP/1.1" 207 318 0.007 - - 0 ---snap--- I suppose some date is invalid and crashes the store. Resultset is: ---snip--- http://sid.in.skyrix.com:80/ zidestore/so/helge/Tasks/12180HTTP/1.1 200 OKIPM.Taskhttp://sid.in.skyrix.com:80/zidestore/so/ helge/Tasks/12180http://sid.in.skyrix.com:80/ zidestore/so/helge/Tasks/12180Thu, 21 Oct 2004 16:07:47 GMTtest1abc def 2004-10-06T22:00:00.000Z2004-10-21T16:07:47.000Z10290high02004-10-06T22:00:00.000Z2004-10-14T21:59:59.000Z10.00http://localhost:20001/Skyrix/wa/activate? oid=12180http://sid.in.skyrix.com:80/zidestore/so/helge/Tasks/ 12230HTTP/1.1 200 OKIPM.Taskhttp://sid.in.skyrix.com:80/zidestore/so/ helge/Tasks/12230http://sid.in.skyrix.com:80/ zidestore/so/helge/Tasks/12230Thu, 21 Oct 2004 16:07:47 GMTtest2dsfg2004-10-06T22:00:00.000Z2004-10-21T16:07:47.000Z10290low02004-10-06T22:00:00.000Z2004-10-21T21:59:59.000Z10.00abc defhttp://localhost:20001/Skyrix/ wa/activate?oid=12230 ---snap--- Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Thu Oct 21 17:46:18 2004 From: evolution@opengroupware.org (Helge Hess) Date: Thu, 21 Oct 2004 18:46:18 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <8D162E5C-237B-11D9-8364-000D93C1A604@opengroupware.org> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098364221.19196.6.camel@s003018577431> <651E2BCB-2372-11D9-8364-000D93C1A604@opengroupware.org> <1098372756.19196.15.camel@s003018577431> <8D162E5C-237B-11D9-8364-000D93C1A604@opengroupware.org> Message-ID: On Oct 21, 2004, at 18:09, Helge Hess wrote: > But when I start the connector in the shell (in GDB), and then Evo, I > still get a crash in: > ---snip--- > ** (evolution-exchange-storage:6887): CRITICAL **: file e2k-result.c: > line 111 (prop_parse): assertion `node->ns != NULL' failed I suppose this is the primary issue and the thing below is a problem resulting from this. > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 32771 (LWP 6887)] > 0x080951c3 in icaltime_to_e2k_time () The dates produces by ZideStore look good, IMHO: ---snip--- 2004-10-06T22:00:00.000Z ---snap--- The only thing I find a bit confusing is that icaltime_to_e2k_time calls itself: ---snip--- #0 0x080951c3 in icaltime_to_e2k_time () #1 0x0809574d in icaltime_to_e2k_time () ---snap--- Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Thu Oct 21 17:57:16 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Thu, 21 Oct 2004 18:57:16 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <8D162E5C-237B-11D9-8364-000D93C1A604@opengroupware.org> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098364221.19196.6.camel@s003018577431> <651E2BCB-2372-11D9-8364-000D93C1A604@opengroupware.org> <1098372756.19196.15.camel@s003018577431> <8D162E5C-237B-11D9-8364-000D93C1A604@opengroupware.org> Message-ID: <1098377836.20616.5.camel@s003018577431> On Thu, 2004-10-21 at 18:09 +0200, Helge Hess wrote: > ---snip--- > 192.168.0.111 - - [21/Oct/2004:18:05:16 GMT] "PROPFIND > /zidestore/so/helge/Tasks/ HTTP/1.1" 401 0 0.003 - - 0 > 192.168.0.111 - - [21/Oct/2004:18:05:16 GMT] "PROPFIND > /zidestore/so/helge/Tasks/ HTTP/1.1" 207 413 0.008 - - 0 > Oct 21 18:05:16 ogo-zidestore-1.3 [6755]: |SxTaskFolder:Tasks| > evolution query: davContentClass = 'urn:content-classes:task' > 192.168.0.111 - - [21/Oct/2004:18:05:16 GMT] "SEARCH > /zidestore/so/helge/Tasks/ HTTP/1.1" 207 3355 0.111 - - 0 > 192.168.0.111 - - [21/Oct/2004:18:07:00 GMT] "PROPFIND > /zidestore/so/helge/NON_IPM_SUBTREE/ HTTP/1.1" 207 318 0.007 - - 0 > ---snap--- > > I suppose some date is invalid and crashes the store. I don't know anything about the internals of the connector so can't help you out with the GDB data. What I do remember is that after a PROPFIND on the NON_IPM_SUBTREE the connector sends a malformed request. This could either be some data without a \n or just opening a connection without sending anything. The connector won't continue if this connection is not closed. Maybe this is part of your problem? Greets, Erik From evolution@opengroupware.org Fri Oct 22 10:10:58 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Fri, 22 Oct 2004 11:10:58 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <651E2BCB-2372-11D9-8364-000D93C1A604@opengroupware.org> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098364221.19196.6.camel@s003018577431> <651E2BCB-2372-11D9-8364-000D93C1A604@opengroupware.org> Message-ID: <1098436258.23348.18.camel@s003018577431> On Thu, 2004-10-21 at 17:03 +0200, Helge Hess wrote: > On Oct 21, 2004, at 15:10, Erik Romijn wrote: > > Actually I have no idea where to look for the source of this error. > > Difficulty here is that I don't have any other examples from which I > > can read the correct format of the request. Do you see anything that is > > likely not to be accepted by ZideStore? > > Yes, I need to look into this. For your script you could probably > convert it to a PUT, not sure. I'll take a look and it and see if I can get it working. What could be very useful is to keep a list of what exactly is working and what is not, with and without ex2ogo in between and who is working on that, in which we could both change things. It would make it easier to see what still needs work and prevent us from doing double work. Do you have a suggestion for a useful system for this? Greetings, Erik From evolution@opengroupware.org Fri Oct 22 10:23:25 2004 From: evolution@opengroupware.org (Helge Hess) Date: Fri, 22 Oct 2004 11:23:25 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <1098436258.23348.18.camel@s003018577431> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098364221.19196.6.camel@s003018577431> <651E2BCB-2372-11D9-8364-000D93C1A604@opengroupware.org> <1098436258.23348.18.camel@s003018577431> Message-ID: <06B97ED6-240C-11D9-8364-000D93C1A604@opengroupware.org> On Oct 22, 2004, at 11:10, Erik Romijn wrote: > What could be very useful is to keep a list of what exactly is working > and what is not, with and without ex2ogo in between and who is working > on that, in which we could both change things. It would make it easier > to see what still needs work and prevent us from doing double work. Do > you have a suggestion for a useful system for this? Just post it to the list if you find something out ;-) I suppose an Evolution/OGo dev blog would be cool as well. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Fri Oct 22 10:39:53 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Fri, 22 Oct 2004 11:39:53 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <06B97ED6-240C-11D9-8364-000D93C1A604@opengroupware.org> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098364221.19196.6.camel@s003018577431> <651E2BCB-2372-11D9-8364-000D93C1A604@opengroupware.org> <1098436258.23348.18.camel@s003018577431> <06B97ED6-240C-11D9-8364-000D93C1A604@opengroupware.org> Message-ID: <1098437993.23853.5.camel@s003018577431> On Fri, 2004-10-22 at 11:23 +0200, Helge Hess wrote: > On Oct 22, 2004, at 11:10, Erik Romijn wrote: > > What could be very useful is to keep a list of what exactly is working > > and what is not, with and without ex2ogo in between and who is working > > on that, in which we could both change things. It would make it easier > > to see what still needs work and prevent us from doing double work. Do > > you have a suggestion for a useful system for this? > > Just post it to the list if you find something out ;-) I suppose an > Evolution/OGo dev blog would be cool as well. I thought there already was an evo-ogo blog at http://quasispace.de/blogs/evo-ogo.php Or is this specifically for the evo-ogo native connector? Greetings, Erik From evolution@opengroupware.org Fri Oct 22 10:51:19 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Fri, 22 Oct 2004 11:51:19 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <1098436258.23348.18.camel@s003018577431> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098364221.19196.6.camel@s003018577431> <651E2BCB-2372-11D9-8364-000D93C1A604@opengroupware.org> <1098436258.23348.18.camel@s003018577431> Message-ID: <1098438679.23855.10.camel@s003018577431> On Fri, 2004-10-22 at 11:10 +0200, Erik Romijn wrote: > On Thu, 2004-10-21 at 17:03 +0200, Helge Hess wrote: > > On Oct 21, 2004, at 15:10, Erik Romijn wrote: > > > Actually I have no idea where to look for the source of this error. > > > Difficulty here is that I don't have any other examples from which I > > > can read the correct format of the request. Do you see anything that is > > > likely not to be accepted by ZideStore? > > > > Yes, I need to look into this. For your script you could probably > > convert it to a PUT, not sure. > > I'll take a look and it and see if I can get it working. I'm getting stuck here on a lack of examples on what data ZideStore would still accept. I see what data the connector sends to ZideStore but I don't have any other examples of applications that send data to zidestore and that already work. For the reading part I just tried the connector on exchange, looked what exchange replied and mangled the zidestore data to look the same. But that method is not possible for writing without having something that can communicate with ZideStore WebDAV and do all the things like storing data. Do you know any source from where I could take example data? Greetings, Erik From evolution@opengroupware.org Fri Oct 22 11:06:03 2004 From: evolution@opengroupware.org (Helge Hess) Date: Fri, 22 Oct 2004 12:06:03 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <1098438679.23855.10.camel@s003018577431> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098364221.19196.6.camel@s003018577431> <651E2BCB-2372-11D9-8364-000D93C1A604@opengroupware.org> <1098436258.23348.18.camel@s003018577431> <1098438679.23855.10.camel@s003018577431> Message-ID: On Oct 22, 2004, at 11:51, Erik Romijn wrote: > I'm getting stuck here on a lack of examples on what data ZideStore > would still accept. The examples are the available applications, that is - Evo + Connector 1.2 - Cadaver - Glow - Apple iCal - MozCal - KOrganizer > I see what data the connector sends to ZideStore but I don't have any > other examples of applications that send data to zidestore and that > already work. ZideStore is not a server with a "strict" API (well, it might evolve into that), it exists for the only reason to provide access for specific native clients. As such it was developed against those apps, not against a specific protocol. So it supports exactly those things which are required by eg Evo 1.2, sometime a bit more, sometimes a bit less ;-). > For the reading part I just tried the connector on exchange, looked > what exchange replied and mangled the zidestore data to look the same. It would be really great if you could collect such request/response combinations (maybe together with some info) in a reference. Eg docs.opengroupware.org might be a good place for that. > But that method is not possible for writing without having something > that can communicate with ZideStore WebDAV and do all the things like > storing data. > Do you know any source from where I could take example data? Evo + Connector 1.2 would get closest. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Fri Oct 22 11:27:40 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Fri, 22 Oct 2004 12:27:40 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098364221.19196.6.camel@s003018577431> <651E2BCB-2372-11D9-8364-000D93C1A604@opengroupware.org> <1098436258.23348.18.camel@s003018577431> <1098438679.23855.10.camel@s003018577431> Message-ID: <1098440860.23862.17.camel@s003018577431> On Fri, 2004-10-22 at 12:06 +0200, Helge Hess wrote: > > On Oct 22, 2004, at 11:51, Erik Romijn wrote: > ZideStore is not a server with a "strict" API (well, it might evolve > into that), it exists for the only reason to provide access for > specific native clients. As such it was developed against those apps, > not against a specific protocol. > > So it supports exactly those things which are required by eg Evo 1.2, > sometime a bit more, sometimes a bit less ;-). Yes, I realized that. What I had in mind for ex2ogo is just mangling it to look like evo 1.2 data. > > For the reading part I just tried the connector on exchange, looked > > what exchange replied and mangled the zidestore data to look the same. > > It would be really great if you could collect such request/response > combinations (maybe together with some info) in a reference. Eg > docs.opengroupware.org might be a good place for that. The mangling required for zidestore->exchange like is already in the source, I could document it better if that helps you out. Is that what you mean? > > But that method is not possible for writing without having something > > that can communicate with ZideStore WebDAV and do all the things like > > storing data. > > Do you know any source from where I could take example data? > > Evo + Connector 1.2 would get closest. Is this still available somewhere? Can't find it on the Novell site. And this is still commercial software right? Greetings, Erik From evolution@opengroupware.org Fri Oct 22 12:15:09 2004 From: evolution@opengroupware.org (Helge Hess) Date: Fri, 22 Oct 2004 13:15:09 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: <1098440860.23862.17.camel@s003018577431> References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098364221.19196.6.camel@s003018577431> <651E2BCB-2372-11D9-8364-000D93C1A604@opengroupware.org> <1098436258.23348.18.camel@s003018577431> <1098438679.23855.10.camel@s003018577431> <1098440860.23862.17.camel@s003018577431> Message-ID: On Oct 22, 2004, at 12:27, Erik Romijn wrote: > Yes, I realized that. What I had in mind for ex2ogo is just mangling it > to look like evo 1.2 data. Yes. >> It would be really great if you could collect such request/response >> combinations (maybe together with some info) in a reference. Eg >> docs.opengroupware.org might be a good place for that. > The mangling required for zidestore->exchange like is already in the > source, I could document it better if that helps you out. > Is that what you mean? No, just the exakt HTTP traffic and the sequences would be already pretty good. Like: 1. GET /exchange/user -> link to GET request trace and response 2. PROPFIND ... -> link to PROPFIND request trace and response etc >> Evo + Connector 1.2 would get closest. > Is this still available somewhere? Can't find it on the Novell site. > And this is still commercial software right? I have no idea, sorry. I suppose its almost impossible to get it now. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Fri Oct 22 15:30:24 2004 From: evolution@opengroupware.org (Helge Hess) Date: Fri, 22 Oct 2004 16:30:24 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098364221.19196.6.camel@s003018577431> <651E2BCB-2372-11D9-8364-000D93C1A604@opengroupware.org> <1098372756.19196.15.camel@s003018577431> <8D162E5C-237B-11D9-8364-000D93C1A604@opengroupware.org> Message-ID: On Oct 21, 2004, at 18:46, Helge Hess wrote: > On Oct 21, 2004, at 18:09, Helge Hess wrote: >> But when I start the connector in the shell (in GDB), and then Evo, I >> still get a crash in: >> ---snip--- >> ** (evolution-exchange-storage:6887): CRITICAL **: file e2k-result.c: >> line 111 (prop_parse): assertion `node->ns != NULL' failed > > I suppose this is the primary issue and the thing below is a problem > resulting from this. OK, found the issue. This is because Connector 2.0.2 only allows for XML namespace prefixes with an exact length of 1. Eg this works: xmlns:d="http://schemas.microsoft.com/mapi/id/{00062003-0000-0000-C000 -000000000046}/" and this breaks: xmlns:abc="http://schemas.microsoft.com/mapi/id/{00062003-0000-0000- C000-000000000046}/" Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Fri Oct 22 17:32:38 2004 From: evolution@opengroupware.org (Helge Hess) Date: Fri, 22 Oct 2004 18:32:38 +0200 Subject: [OGo-Evolution] working mangling daemon allowing basic OGo-Evolution In-Reply-To: References: <1097228268.2640.0.camel@dhcp246> <786480E2-21D4-11D9-94D8-000D93C1A604@opengroupware.org> <1098271330.10064.12.camel@s003018577431> <42224574-22EA-11D9-8364-000D93C1A604@opengroupware.org> <1098348736.15486.3.camel@s003018577431> <756944C6-2346-11D9-8364-000D93C1A604@opengroupware.org> <1098364221.19196.6.camel@s003018577431> <651E2BCB-2372-11D9-8364-000D93C1A604@opengroupware.org> <1098372756.19196.15.camel@s003018577431> <8D162E5C-237B-11D9-8364-000D93C1A604@opengroupware.org> Message-ID: On Oct 22, 2004, at 16:30, Helge Hess wrote: > OK, found the issue. This is because Connector 2.0.2 only allows for > XML namespace prefixes with an exact length of 1. > Eg this works: > > xmlns:d="http://schemas.microsoft.com/mapi/id/{00062003-0000-0000- > C000-000000000046}/" > > and this breaks: > > xmlns:abc="http://schemas.microsoft.com/mapi/id/{00062003-0000-0000- > C000-000000000046}/" Just for the record, found another issue ;-) The categories of a task were not probably declared as mv.string and made the Connector crash. Fixed in r278. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Sun Oct 24 22:29:38 2004 From: evolution@opengroupware.org (Chris H) Date: Sun, 24 Oct 2004 17:29:38 -0400 Subject: [OGo-Evolution] doc request Message-ID: <200410241729.38866.chris123@magma.ca> Greets; In preparation for the 1.0 release of OGo I have started reorganizing the content on the documentation site. This is currently viewable under the non public URL http://docs.opengroupware.org/content/ It will go live to the general public when its complete and accessible under a new tab. This page will be a series of direct links to collected and sorted documentation in the archive on specific subjects. Only one link is active at this time as a demo. In order to get this done would all OGo users pls consider uploading their documentation, notes, articles etc into their accounts, choose an appropriate title, and make sure the state has been set to publish. If you dont have an account pls consider registering and creating an account on the site. If you need support, pls email documentation@opengroupware.org or subscribe to the list available from http://mail.opengroupware.org/mailman/listinfo/documentation I hope to have internationalization complete (no promises on that) so the language of choice is your call. English remains at this time however the most supported language internationally. Its your call however as it your documentation and all additions are of course most welcomed. /ch From evolution@opengroupware.org Mon Oct 25 12:41:58 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Mon, 25 Oct 2004 13:41:58 +0200 Subject: [OGo-Evolution] zidestore trunk having trouble with evo-ogo Message-ID: <1098704518.1029.24.camel@s003018577431> Hello, I've just updated my system to the suse trunk packages of 22oct and I have several strange results with evo-ogo. Without ex2ogo the connector does not even recognize zidestore as an exchange server (helge fixed that iirc) and with ex2ogo it has lots of trouble in the address book (lots of address books result in 'unable to open'). Is this a known bug in that trunk version or is there something else wrong here? Greetings, Erik From evolution@opengroupware.org Mon Oct 25 13:00:25 2004 From: evolution@opengroupware.org (Helge Hess) Date: Mon, 25 Oct 2004 14:00:25 +0200 Subject: [OGo-Evolution] zidestore trunk having trouble with evo-ogo In-Reply-To: <1098704518.1029.24.camel@s003018577431> References: <1098704518.1029.24.camel@s003018577431> Message-ID: <747E7903-267D-11D9-98F6-000D93C1A604@opengroupware.org> On Oct 25, 2004, at 13:41, Erik Romijn wrote: > I've just updated my system to the suse trunk packages of 22oct and I > have several strange results with evo-ogo. Should work just fine. Please ensure that SOPE is also up to date. > Without ex2ogo the connector does not even recognize zidestore as an > exchange server (helge fixed that iirc) I didn't work on Evo/ZideStore since the 22nd. > and with ex2ogo it has lots of > trouble in the address book (lots of address books result in 'unable to > open'). Can't say anything about this. > Is this a known bug in that trunk version or is there something else > wrong here? "something else" ;-) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From evolution@opengroupware.org Mon Oct 25 17:16:58 2004 From: evolution@opengroupware.org (Erik Romijn) Date: Mon, 25 Oct 2004 18:16:58 +0200 Subject: [OGo-Evolution] zidestore trunk having trouble with evo-ogo In-Reply-To: <747E7903-267D-11D9-98F6-000D93C1A604@opengroupware.org> References: <1098704518.1029.24.camel@s003018577431> <747E7903-267D-11D9-98F6-000D93C1A604@opengroupware.org> Message-ID: <1098721018.3898.15.camel@s003018577431> On Mon, 2004-10-25 at 14:00 +0200, Helge Hess wrote: > On Oct 25, 2004, at 13:41, Erik Romijn wrote: > > I've just updated my system to the suse trunk packages of 22oct and I > > have several strange results with evo-ogo. Ok everything is fixed now. The problems with my zidestore not being recognized as as an exchange server were caused by using the wrong ZideStore server :-) The problems with the address book were caused by a bug in ex2ogo. The regexp mangling the folder listing assumed that ZideStore returned an item for the Overview folder, it seems that the newest ZideStore does not do this anymore. A new ex2ogo is available at: http://oracle.toltech.nl/~erik/ex2ogo-0.1.2.pl Note that I don't test backward compatibility with any older trunk versions. May work, may not ;-) A strange thing has happened as we were just doing some final tests on it - evolution showed both an Overview and a Calendar for calendar items. Overview contained the users own items, Calendar also included all the items from the other users. I don't think ZideStore should allow this ;-) Note that overview and calendar are also mixed up by ex2ogo. I'll put some time in a detailed description of what is going wrong here tomorrow. It also seems that a minor bug has slipped in the display of contacts. Their e-mail address is now displayed in a form of: MAILTO:[mailing address] Should not be too hard to fix. I will soon start with structured testing to make an overview of what exactly is still missing. I'm also planning to make a good list of what exactly is mangled by ex2ogo - that should help Helge with merging all neccesary changes into ZideStore in the end. Greetings, Erik From evolution@opengroupware.org Mon Oct 25 21:06:12 2004 From: evolution@opengroupware.org (Helge Hess) Date: Mon, 25 Oct 2004 22:06:12 +0200 Subject: [OGo-Evolution] zidestore trunk having trouble with evo-ogo In-Reply-To: <1098721018.3898.15.camel@s003018577431> References: <1098704518.1029.24.camel@s003018577431> <747E7903-267D-11D9-98F6-000D93C1A604@opengroupware.org> <1098721018.3898.15.camel@s003018577431> Message-ID: <51E2CC91-26C1-11D9-98F6-000D93C1A604@opengroupware.org> On Oct 25, 2004, at 18:16, Erik Romijn wrote: > A strange thing has happened as we were just doing some final tests on > it - evolution showed both an Overview and a Calendar for calendar > items. > Overview contained the users own items, Calendar also included all the > items from the other users. I don't think ZideStore should allow > this ;-) I'm not sure whether you know the rational behind Overview and Calendar? User/Calendar contains only those items which have the read_access_group set to NULL (labeled private in the WebUI). User/Overview shows the same set of items like the WebUI calendar view if the focus is on the account. This includes all appointments which have the account as the participant. So, Calendar is "mostly" a subset of Overview. > It also seems that a minor bug has slipped in the display of contacts. > Their e-mail address is now displayed in a form of: > MAILTO:[mail