From groupdav@opengroupware.org Fri Feb 1 11:02:43 2008 From: groupdav@opengroupware.org (=?ISO-8859-15?Q?Samuli_Sepp=E4nen?=) Date: Fri, 01 Feb 2008 13:02:43 +0200 Subject: [GroupDAV] Building GroupDAV connector Message-ID: <47A2FC53.4060404@tietoteema.fi> Hi! I just today started creating the build environment for the Funambol GroupDAV connector. I found some bugs and have some suggestions that would make contributions easier. After a brief struggle with various *.properties files in "funambol-groupdav-connector" and "jgroupdav" I managed to go through the build process, at least almost. The problem was that junit tests failed, which caused the build to fail. The reason for the failure seems obvious: [junit] Testcase: beginSlowAndEnd(net.bionicmessage.funambol.groupdav.calendar.CalendarSyncSourceAsTodoTest): Caused an ERROR [junit] /home/sasepp/.groupdavconnector_todo_test_properties (No such file or directory) [junit] java.io.FileNotFoundException: As "find -name ".groupdav*" did not yield anything useful, I suppose these are not currently included in git repos. Could Matt add these files to git and/or send them to me or this list? I wouldn't want to strip out these junit tests just to get the connector to build... Considering the struggle with the various jar files paths in *.properties files... Wouldn't it be possible to write the ant build files so that by default only general purpose *.properties files existed and then user could override them with his/her own *.properties file where necessary? Generic build files coupled with a appropriate BUILDING.txt would make it much easier to get started in GroupDAV connector building and patching. I can write the BUILDING.txt myself, but I'd rather not touch the ant build files, being very wet behind the ears when it comes to ant. Best regards, Samuli From groupdav@opengroupware.org Fri Feb 1 11:51:23 2008 From: groupdav@opengroupware.org (Mathew McBride) Date: Fri, 01 Feb 2008 22:51:23 +1100 Subject: [GroupDAV] Building GroupDAV connector In-Reply-To: <47A2FC53.4060404@tietoteema.fi> Message-ID: The default ant target will do the building, jar/s4j and javadocs, but just doing "ant jar" will build the s4j for you. The junit test involved runs a simulated Funambol session. If you define connector.sources.default(i.e /groupdav/Calendar), connector.serverhost(http://localhost:2000), test.user and test.pass, in a properties file (mentioned in the source file) will run a few simulated syncs with various steps. There is one for events, tasks and contacts, and two for data conversion. I usually fire off the build from an IDE (NetBeans) using the "jar" target = - sorry I didn't notice this. I'll figure out how to stop these tests occurring when not configured. Thanks for the suggestion re build instructions and to Peter do re creating sync sources. I'll put them into the next update. On 1/2/08 10:02 PM, "Samuli Sepp=E4nen" wrote= : > Hi! >=20 > I just today started creating the build environment for the Funambol > GroupDAV connector. I found some bugs and have some suggestions that > would make contributions easier. >=20 > After a brief struggle with various *.properties files in > "funambol-groupdav-connector" and "jgroupdav" I managed to go through > the build process, at least almost. The problem was that junit tests > failed, which caused the build to fail. The reason for the failure seems > obvious: >=20 > [junit] Testcase: > beginSlowAndEnd(net.bionicmessage.funambol.groupdav.calendar.CalendarSync= Sourc > eAsTodoTest):=20 > Caused an ERROR > [junit] /home/sasepp/.groupdavconnector_todo_test_properties (No such > file or directory) > [junit] java.io.FileNotFoundException: >=20 > As "find -name ".groupdav*" did not yield anything useful, I suppose > these are not currently included in git repos. Could Matt add these > files to git and/or send them to me or this list? I wouldn't want to > strip out these junit tests just to get the connector to build... >=20 > Considering the struggle with the various jar files paths in > *.properties files... Wouldn't it be possible to write the ant build > files so that by default only general purpose *.properties files existed > and then user could override them with his/her own *.properties file > where necessary? >=20 > Generic build files coupled with a appropriate BUILDING.txt would make > it much easier to get started in GroupDAV connector building and > patching. I can write the BUILDING.txt myself, but I'd rather not touch > the ant build files, being very wet behind the ears when it comes to ant. >=20 > Best regards, >=20 > Samuli >=20 >=20 From groupdav@opengroupware.org Fri Feb 1 12:58:50 2008 From: groupdav@opengroupware.org (=?ISO-8859-1?Q?Samuli_Sepp=E4nen?=) Date: Fri, 01 Feb 2008 14:58:50 +0200 Subject: [GroupDAV] Building GroupDAV connector In-Reply-To: References: Message-ID: <47A3178A.7020104@tietoteema.fi> Mathew McBride ha scritto: > The default ant target will do the building, jar/s4j and javadocs, but just > doing "ant jar" will build the s4j for you. Thanks fot the tip, it worked like a charm. > The junit test involved runs a simulated Funambol session. If you define > connector.sources.default(i.e /groupdav/Calendar), > connector.serverhost(http://localhost:2000), test.user and test.pass, in a > properties file (mentioned in the source file) will run a few simulated > syncs with various steps. There is one for events, tasks and contacts, and > two for data conversion. I'll have to check these out too. > I usually fire off the build from an IDE (NetBeans) using the "jar" target - > sorry I didn't notice this. I'll figure out how to stop these tests > occurring when not configured. > > Thanks for the suggestion re build instructions and to Peter do re creating > sync sources. I'll put them into the next update. Ok, I'll be writing a BUILDING.txt then. Samuli From groupdav@opengroupware.org Fri Feb 1 15:27:34 2008 From: groupdav@opengroupware.org (Sandy Lelarge) Date: Fri, 01 Feb 2008 16:27:34 +0100 Subject: [GroupDAV] put an appointement with team read access Message-ID: <47A33A66.3060907@cg51.fr> This is a multi-part message in MIME format. --------------020603030400080308060303 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit We are using ogo since about 3 years now, And I tried funambol for sync. And every thing seems to work fine. But, We usually create our appointment with team read access. And I wonder how to do this with groupdav. I'm using /Overview as Url to get all my appointments but when I put one in my client and sync it. The appointment read access are set to me and all intranet. Is it possible to make a specific upload url ? (something like /dav/%USER%//%USER%/Calendar ?) -- M Sandy Lelarge Conseil Général de la Marne Service Informatique 2 bis, rue de Jessaint 51038 Châlons en Champagne cedex tel : 03.26.69.39.29 email : lelarges@cg51.fr ****************************************************************************************************************************** Ce message ou ses pieces jointes peuvent contenir des informations confidentielles a l'intention exclusive de son destinataire et est couvert par le secret professionnel. Toute utilisation, divulgation ou reproduction de son contenu sont strictement interdits. Si vous avez recu ce message par erreur, merci de le notifier a son expediteur et d'en detruire toute copie. Le present message pouvant-etre altere a notre insu, le conseil général de la Marne ne peut pas etre engage par son contenu. ****************************************************************************************************************************** --------------020603030400080308060303 Content-Type: text/x-vcard; charset=utf-8; name="lelarges.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="lelarges.vcf" begin:vcard fn:Sandy Lelarge n:Lelarge;Sandy org;quoted-printable:Conseil g=C3=A9n=C3=A9ral de la marne;Service informatique adr:;;2 bis, rue de jessaint;Chalons en champagne;;51000;France email;internet:lelarges@cg51.fr tel;work:0326693929 note;quoted-printable:-----BEGIN PGP PUBLIC KEY BLOCK-----=0D=0A= Version: GnuPG v1.4.8 (MingW32)=0D=0A= =0D=0A= mI0ER2p4/wEEAL6PiUo/TzRFY0I/ohXVPUgTFj/SA3l6wfbTQo4MnuJqy8mB+hpU=0D=0A= hBA3GkVq6W8CnYwIiNDCNiShKPXyBCUK3oCwrZvxwIdVyTzAHehN29wKyxOlP69M=0D=0A= 5tdHyT3G52hOMAgqnlkGmdvx0UJMwnlYT49SNx9OuA/1jJOLGxlz62fRABEBAAG0=0D=0A= IFNhbmR5IExlbGFyZ2UgPGxlbGFyZ2VzQGNnNTEuZnI+iLwEEwECACYFAkdqeP8C=0D=0A= GyMFCQlmAYAGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRCWY9OD5NOF7TXOA/9O=0D=0A= 65qcaf/1jRaXW7hWHbdDE5TR0n+LT2y1FYHsFfBRyNxFYwYPXsib6InXuOVlG6rr=0D=0A= 9+ngfnNVh11rlv9gAfWPy61yp/9yZzRYQKggKYhR7LAGkrlJoEJcr0ZYmNsNaAG8=0D=0A= ocStamUjWVTNrrUZssO18KnplzrF6YCMzwEl3wf4triNBEdqeP8BBADrpOPVGa5q=0D=0A= zOnRLHVKNcdIj9DoG5Eo3B44jCbhEHlgVE8Dq8SF+ZGu83B5xMVU5CJ/QR0z8jyz=0D=0A= AEiL5g9v/apJ3accdMLPaOU4SZSKOztruqAuVH7f6A9wiuE56tbVB9Z1b2l0Kvdn=0D=0A= EOAltS4zMHEUcfZsxrP8dgU3XYwawL7iBwARAQABiKUEGAECAA8FAkdqeP8CGwwF=0D=0A= CQlmAYAACgkQlmPTg+TThe2eIAP8CTMyUl7qWNp3ODCYORkkqQ39vqhVT40QbAKt=0D=0A= R/dGSsZZCq5e9CYF3MfdLL6Xzsj6IgNxF5kYBvhVS26C56QLQk7pZiQ3BsrhXtwE=0D=0A= FkvMIOX0rCtAmmXbhbqEaf1CIHBHKxZMlfS1ha7sjRtwIf4RKmbHPAfSQFWhgCni=0D=0A= R4vpLg4=3D=0D=0A= =3D1ROJ=0D=0A= -----END PGP PUBLIC KEY BLOCK-----=0D=0A= x-mozilla-html:TRUE url:http://www.marne.fr version:2.1 end:vcard --------------020603030400080308060303-- From groupdav@opengroupware.org Fri Feb 1 21:28:12 2008 From: groupdav@opengroupware.org (Wolfgang Sourdeau) Date: Fri, 01 Feb 2008 16:28:12 -0500 Subject: [GroupDAV] =?utf-8?Q?The Inverse Team is pleased to announce the 0.65 release of the "SOGo Connector" extension for Thunderbird. Message-ID: <3ed1-47a38f00-13-b7472ab0@189085263> =3D=3D=3D What is the SOGo Connector =3D=3D=3D This extension transforms Thunderbird into a full DAV client for groupware servers such as SOGo, OpenGroupware.org or Citadel. It does this by adding support for remote DAV address books and by adding features to be used along with the Lightning calendar extension. More information can be found on our website : http://www.inverse.ca/contributions/sogo_connector.html =3D=3D=3D What is SOGo =3D=3D=3D SOGo is a free and modern scalable groupware server. It offers shared calendars, address books and emails through your favorite Web browser or by using a native client such as Mozilla Thunderbird and Lightning. SOGo is standard-compliant and supports CalDAV, CardDAV, GroupDAV and reuses existing IMAP, SMTP and database servers - making the solution easy to deploy and interoperable with many applications. SOGo features : * Scalable architecture suitable for deployments from dozen to many thousand users * Rich Web-based interface that shares the look and feel, the features and the data of Mozilla Thunderbird and Lightning * Improved integration with Mozilla Thunderbird and Lighthing by using the SOGo Connector * Two-way synchronization support with any SyncML-capable devices (BlackBerry, Palm, Windows CE, etc.) by using the Funambol SOGo Connector and many more! SOGo and our connectors are completely free. We have a demo website where you can experience SOGo from the Web or your preferred CalDAV client: http://sogo-demo.inverse.ca/ =3D=3D=3D Changes since the last release =3D=3D=3D * added asynchronous autocompletion * added the handling of organizers for whom the user id is an email address * fixed a crash occuring during autocompletion operations on LDAP addressbooks * reenabled the ability to download cards from OGo (upload still doesn't work) * added patch from https://bugzilla.mozilla.org/show_bug.cgi?id=3D408727 to speedup the display of the monthly view in Lightning =3D=3D=3D Getting the SOGo Connector =3D=3D=3D SOGo Connector is free software and is distributed under the GNU GPL v. 2. As such, you are free to download and use it from : http://www.inverse.ca/groupware/plugins/sogo-connector-0.65.xpi Documentation about the installation and configuration of SOGo is available from : http://www.inverse.ca/contributions/sogo_connector.html ANN: SOGo Connector v0.65?= date: Fri, 01 Feb 2008 16:28:12 -0500 MIME-Version: 1.0 content-type: text/plain; charset="utf-8" reply-to: "Wolfgang Sourdeau" User-Agent: SOGoMail 1.0 content-length: 3204 content-transfer-encoding: quoted-printable The Inverse Team is pleased to announce the 0.65 release of the "SOGo Connector" extension for Thunderbird. =3D=3D=3D What is the SOGo Connector =3D=3D=3D This extension transforms Thunderbird into a full DAV client for groupware servers such as SOGo, OpenGroupware.org or Citadel. It does this by adding support for remote DAV address books and by adding features to be used along with the Lightning calendar extension. More information can be found on our website : http://www.inverse.ca/contributions/sogo_connector.html =3D=3D=3D What is SOGo =3D=3D=3D SOGo is a free and modern scalable groupware server. It offers shared calendars, address books and emails through your favorite Web browser or by using a native client such as Mozilla Thunderbird and Lightning. SOGo is standard-compliant and supports CalDAV, CardDAV, GroupDAV and reuses existing IMAP, SMTP and database servers - making the solution easy to deploy and interoperable with many applications. SOGo features : * Scalable architecture suitable for deployments from dozen to many thousand users * Rich Web-based interface that shares the look and feel, the features and the data of Mozilla Thunderbird and Lightning * Improved integration with Mozilla Thunderbird and Lighthing by using the SOGo Connector * Two-way synchronization support with any SyncML-capable devices (BlackBerry, Palm, Windows CE, etc.) by using the Funambol SOGo Connector and many more! SOGo and our connectors are completely free. We have a demo website where you can experience SOGo from the Web or your preferred CalDAV client: http://sogo-demo.inverse.ca/ =3D=3D=3D Changes since the last release =3D=3D=3D * added asynchronous autocompletion * added the handling of organizers for whom the user id is an email address * fixed a crash occuring during autocompletion operations on LDAP addressbooks * reenabled the ability to download cards from OGo (upload still doesn't work) * added patch from https://bugzilla.mozilla.org/show_bug.cgi?id=3D408727 to speedup the display of the monthly view in Lightning =3D=3D=3D Getting the SOGo Connector =3D=3D=3D SOGo Connector is free software and is distributed under the GNU GPL v. 2. As such, you are free to download and use it from : http://www.inverse.ca/groupware/plugins/sogo-connector-0.65.xpi Documentation about the installation and configuration of SOGo is available from : http://www.inverse.ca/contributions/sogo_connector.html =3D=3D=3D Getting support =3D=3D=3D For any questions, do not hesitate to contact us by writing an email to : support@inverse.ca Inverse offers professional services around SOGo to help organizations deploy the solution and migrate from their legacy systems. -- Wolfgang Sourdeau T: +1 514 989-2000 ext. 2602 C: +1 514 755-3520 AVIS - Ce courriel pourrait contenir des renseignements confidentiels ou privil=C3=A9gi=C3=A9s. Si vous n'en =C3=AAtes pas le v=C3=A9ritable destinataire, veuillez nous aviser imm=C3=A9diatement. Merci. NOTICE - This e-mail may contain confidential or privileged information. If you are not the intended recipient, please notify us immediately. Thank you. From groupdav@opengroupware.org Fri Feb 1 21:29:18 2008 From: groupdav@opengroupware.org (Wolfgang Sourdeau) Date: Fri, 01 Feb 2008 16:29:18 -0500 Subject: [GroupDAV] ANN: SOGo Connector v0.65 Message-ID: <3ed1-47a38f00-19-b7472ab0@189085305> The Inverse Team is pleased to announce the 0.65 release of the "SOGo Connector" extension for Thunderbird. =3D=3D=3D What is the SOGo Connector =3D=3D=3D This extension transforms Thunderbird into a full DAV client for groupware servers such as SOGo, OpenGroupware.org or Citadel. It does this by adding support for remote DAV address books and by adding features to be used along with the Lightning calendar extension. More information can be found on our website : http://www.inverse.ca/contributions/sogo_connector.html =3D=3D=3D What is SOGo =3D=3D=3D SOGo is a free and modern scalable groupware server. It offers shared calendars, address books and emails through your favorite Web browser or by using a native client such as Mozilla Thunderbird and Lightning. SOGo is standard-compliant and supports CalDAV, CardDAV, GroupDAV and reuses existing IMAP, SMTP and database servers - making the solution easy to deploy and interoperable with many applications. SOGo features : * Scalable architecture suitable for deployments from dozen to many thousand users * Rich Web-based interface that shares the look and feel, the features and the data of Mozilla Thunderbird and Lightning * Improved integration with Mozilla Thunderbird and Lighthing by using the SOGo Connector * Two-way synchronization support with any SyncML-capable devices (BlackBerry, Palm, Windows CE, etc.) by using the Funambol SOGo Connector and many more! SOGo and our connectors are completely free. We have a demo website where you can experience SOGo from the Web or your preferred CalDAV client: http://sogo-demo.inverse.ca/ =3D=3D=3D Changes since the last release =3D=3D=3D * added asynchronous autocompletion * added the handling of organizers for whom the user id is an email address * fixed a crash occuring during autocompletion operations on LDAP addressbooks * reenabled the ability to download cards from OGo (upload still doesn't work) * added patch from https://bugzilla.mozilla.org/show_bug.cgi?id=3D408727 to speedup the display of the monthly view in Lightning =3D=3D=3D Getting the SOGo Connector =3D=3D=3D SOGo Connector is free software and is distributed under the GNU GPL v. 2. As such, you are free to download and use it from : http://www.inverse.ca/groupware/plugins/sogo-connector-0.65.xpi Documentation about the installation and configuration of SOGo is available from : http://www.inverse.ca/contributions/sogo_connector.html =3D=3D=3D Getting support =3D=3D=3D For any questions, do not hesitate to contact us by writing an email to : support@inverse.ca Inverse offers professional services around SOGo to help organizations deploy the solution and migrate from their legacy systems. -- Wolfgang Sourdeau T: +1 514 989-2000 ext. 2602 C: +1 514 755-3520 AVIS - Ce courriel pourrait contenir des renseignements confidentiels ou privil=C3=A9gi=C3=A9s. Si vous n'en =C3=AAtes pas le v=C3=A9ritable destinataire, veuillez nous aviser imm=C3=A9diatement. Merci. NOTICE - This e-mail may contain confidential or privileged information. If you are not the intended recipient, please notify us immediately. Thank you. From groupdav@opengroupware.org Thu Feb 7 09:30:39 2008 From: groupdav@opengroupware.org (Helge Hess) Date: Thu, 7 Feb 2008 10:30:39 +0100 Subject: [GroupDAV] Re: [Fwd: Re: [Fwd: Re: 0.63 broken? was: Re: UTF-8 and Quoted Printable Support]] In-Reply-To: <47AA8CF5.40505@digitalROCK.de> References: <47A8C1E0.6020502@pfr.de> <47AA8CF5.40505@digitalROCK.de> Message-ID: <6E2D7193-E6C4-45CD-B923-BB404676903E@opengroupware.org> On 07.02.2008, at 05:45, Ralf Becker wrote: > I announce the addressbook URL as GroupDAV "vcard-collection" if you > do a PROPFIND on the underlying collection. > > If you do a PROPFIND the the addressbook URL itself, I have disabled > the GroupDAV ressource type of the collection itself (not the > contact nods of cause), as it doubles the folder in KOrganizer :-( I'm slightly confused because KOrganizer doesn't deal with addressbooks? :-) You probably refer to KAddressbook (or Kontact as the shell for it). Anyways, this is probably a bug in Kontact/KAddrBook. To me it sounds like the fetch does not properly filter out the 'self' URL in PROPFIND results. Request: PROPFIND /folder/ Response: /folder/ <= /folder/287837.ics /folder/287838.ics /folder/287839.ics Note that the request URL is included in the results. BTW: this also confuses Windows WebFolders, which is why OGo has some special handling for those. > I can now of cause add a USER_AGENT specific handing to return it > for the SOGO connector and disable it only for KOrganizer. It's not > a nice solution, Its a crappy solution. > better would be if we can agree how this should be handled according > to the GroupDAV standard and we all implement it that way. This is already specified in WebDAV. Kontact needs to properly process the self URL. If it does, the server can actually deliver *both* formats. After all the 'self' URL is to be ignored anyways ... > I also CC'ed the GroupDAV list, hoping that's Ok, as I'm not > familiar with the behavior on that list. Well, I would suggest to post such stuff to the GroupDAV list exclusively! :-) Greets, Helge -- Helge Hess http://www.helgehess.eu/ From groupdav@opengroupware.org Wed Feb 13 05:43:59 2008 From: groupdav@opengroupware.org (=?ISO-8859-1?Q?Samuli_Sepp=E4nen?=) Date: Wed, 13 Feb 2008 07:43:59 +0200 Subject: [GroupDAV] Funambol GroupDAV connector: OGo ATTENDEE fields get stripped away Message-ID: <47B2839F.6060906@tietoteema.fi> Hi! The new version of the GroupDAV connector works really well, but I found a serious problem in it. I don't know how/if other devices/groupware servers are affected, but this is how the bug triggered: - Create a new event in OGo which has write access to "All intranet" and several ATTENDEE fields (=many participants) - Sync the event to a (Nokia) phone - Modify the event in Nokia - Sync the event back to OGo Now, as long as the user has write access to the event, the event gets overwritten. The problem is that now there's only one ATTENDEE (participant) - all others are gone. The thing is that simpler devices, like Nokia, have no concept of participants; their calendar is just a personal calendar. Funambol has it's own ICalMergeUtils class for calendar merging changes to calendars, but it is only used in GroupDAV connector test classes. So, is there any calendar merging functionality in GroupDAV connector yet? If so, where is it? If not, where should it be? Best regards, Samuli Seppänen From groupdav@opengroupware.org Wed Feb 13 06:54:53 2008 From: groupdav@opengroupware.org (Mathew McBride) Date: Wed, 13 Feb 2008 17:54:53 +1100 Subject: [GroupDAV] Funambol GroupDAV connector: OGo ATTENDEE fields get stripped away In-Reply-To: <47B2839F.6060906@tietoteema.fi> Message-ID: Not at the moment. It can be added quite easily. I'll add some code to carr= y the attendee properties from the stored copy to one posted to the server fo= r you to try out.=20 (If there are any other properties that should also be 'carried over', let me know) Attendee is one of the properties currently not converted from/to, though Windows Mobile does support it. On 13/2/08 4:43 PM, "Samuli Sepp=E4nen" wrote= : > Hi! >=20 >=20 > So, is there any calendar merging functionality in GroupDAV connector > yet? If so, where is it? If not, where should it be? >=20 > Best regards, >=20 > Samuli Sepp=E4nen From groupdav@opengroupware.org Wed Feb 13 08:58:15 2008 From: groupdav@opengroupware.org (=?ISO-8859-1?Q?Samuli_Sepp=E4nen?=) Date: Wed, 13 Feb 2008 10:58:15 +0200 Subject: [GroupDAV] Funambol GroupDAV connector: OGo ATTENDEE fields get stripped away In-Reply-To: References: Message-ID: <47B2B127.60901@tietoteema.fi> Ok, great! I'll see if there are any other Zidestore properties that cause problems. If you fix the ATTENDEE issue I can most likely fix the rest of the property problems myself and send a patch. Samuli > Not at the moment. It can be added quite easily. I'll add some code to carry > the attendee properties from the stored copy to one posted to the server for > you to try out. > > (If there are any other properties that should also be 'carried over', let > me know) > > Attendee is one of the properties currently not converted from/to, though > Windows Mobile does support it. > On 13/2/08 4:43 PM, "Samuli Seppänen" wrote: > >> Hi! >> >> >> So, is there any calendar merging functionality in GroupDAV connector >> yet? If so, where is it? If not, where should it be? >> >> Best regards, >> >> Samuli Seppänen > From groupdav@opengroupware.org Wed Feb 13 09:54:44 2008 From: groupdav@opengroupware.org (Mathew McBride) Date: Wed, 13 Feb 2008 20:54:44 +1100 Subject: [GroupDAV] Funambol GroupDAV connector: OGo ATTENDEE fields get stripped away In-Reply-To: <47B2B127.60901@tietoteema.fi> Message-ID: Code is now in git ( http://repo.or.cz/w/funambol-groupdav-connector.git ). I've also carried over ORGANIZER for the benefit of Citadel users. On 13/2/08 7:58 PM, "Samuli Sepp=E4nen" wrote= : > Ok, great! I'll see if there are any other Zidestore properties that > cause problems. If you fix the ATTENDEE issue I can most likely fix the > rest of the property problems myself and send a patch. >=20 > Samuli >=20 >> Not at the moment. It can be added quite easily. I'll add some code to c= arry >> the attendee properties from the stored copy to one posted to the server= for >> you to try out. >>=20 >> (If there are any other properties that should also be 'carried over', l= et >> me know) >>=20 >> Attendee is one of the properties currently not converted from/to, thoug= h >> Windows Mobile does support it. >> On 13/2/08 4:43 PM, "Samuli Sepp=E4nen" wr= ote: >>=20 >>> Hi! >>>=20 >>>=20 >>> So, is there any calendar merging functionality in GroupDAV connector >>> yet? If so, where is it? If not, where should it be? >>>=20 >>> Best regards, >>>=20 >>> Samuli Sepp=E4nen >>=20 From groupdav@opengroupware.org Mon Feb 18 14:13:33 2008 From: groupdav@opengroupware.org (=?ISO-8859-1?Q?Samuli_Sepp=E4nen?=) Date: Mon, 18 Feb 2008 16:13:33 +0200 Subject: [GroupDAV] Funambol GroupDAV connector: OGo ATTENDEE fields get stripped away In-Reply-To: References: Message-ID: <47B9928D.8050307@tietoteema.fi> I believe that OGo uses the ORGANIZER field too. I checked out the latest connector version and will test it tomorrow. I'll report on how it works. Btw. I'll be pushing my updated "Nokia S60 <-> Funambol 6.5 <-> GroupDAV connector 2 <-> OGo 1.1.7" sync documentation to the OGo documentation plone in a few weeks, so stay tuned :) Samuli > Code is now in git ( http://repo.or.cz/w/funambol-groupdav-connector.git ). > I've also carried over ORGANIZER for the benefit of Citadel users. > > > On 13/2/08 7:58 PM, "Samuli Seppänen" wrote: > >> Ok, great! I'll see if there are any other Zidestore properties that >> cause problems. If you fix the ATTENDEE issue I can most likely fix the >> rest of the property problems myself and send a patch. >> >> Samuli >> >>> Not at the moment. It can be added quite easily. I'll add some code to carry >>> the attendee properties from the stored copy to one posted to the server for >>> you to try out. >>> >>> (If there are any other properties that should also be 'carried over', let >>> me know) >>> >>> Attendee is one of the properties currently not converted from/to, though >>> Windows Mobile does support it. >>> On 13/2/08 4:43 PM, "Samuli Seppänen" wrote: >>> >>>> Hi! >>>> >>>> >>>> So, is there any calendar merging functionality in GroupDAV connector >>>> yet? If so, where is it? If not, where should it be? >>>> >>>> Best regards, >>>> >>>> Samuli Seppänen > From groupdav@opengroupware.org Tue Feb 19 15:45:53 2008 From: groupdav@opengroupware.org (=?ISO-8859-1?Q?Samuli_Sepp=E4nen?=) Date: Tue, 19 Feb 2008 17:45:53 +0200 Subject: [GroupDAV] Funambol GroupDAV connector: OGo ATTENDEE fields get stripped away In-Reply-To: <47B9928D.8050307@tietoteema.fi> References: <47B9928D.8050307@tietoteema.fi> Message-ID: <47BAF9B1.1000506@tietoteema.fi> I got the new connector version installed and tested to see if the ATTENDEE problem was still present. It seems that it works but not the way it's supposed: SUMMARY:OGo ATTENDEE test LOCATION:Changed in Nokia ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=FALSE;CN=Samuli Seppänen:MAILTO:samuli.seppanen@tietoteema.fi ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=FALSE;CN=Samuli Seppänen:MAILTO:samuli.seppanen@tietoteema.fi ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=FALSE;CN=Samuli Seppänen:MAILTO:samuli.seppanen@tietoteema.fi ORGANIZER;CN=Samuli Seppänen:MAILTO:samuli.seppanen@tietoteema.fi This event had three participants, but it seems that the first ATTENDEE is fetched three times, instead of each participant one time. Do you have a quick fix for this or shall I dig into the sources more deeply? Best regards, Samuli > I believe that OGo uses the ORGANIZER field too. I checked out the > latest connector version and will test it tomorrow. I'll report on how > it works. > > Btw. I'll be pushing my updated "Nokia S60 <-> Funambol 6.5 <-> GroupDAV > connector 2 <-> OGo 1.1.7" sync documentation to the OGo documentation > plone in a few weeks, so stay tuned :) > > Samuli > > >> Code is now in git ( >> http://repo.or.cz/w/funambol-groupdav-connector.git ). >> I've also carried over ORGANIZER for the benefit of Citadel users. >> >> >> On 13/2/08 7:58 PM, "Samuli Seppänen" >> wrote: >> >>> Ok, great! I'll see if there are any other Zidestore properties that >>> cause problems. If you fix the ATTENDEE issue I can most likely fix the >>> rest of the property problems myself and send a patch. >>> >>> Samuli >>> >>>> Not at the moment. It can be added quite easily. I'll add some code >>>> to carry >>>> the attendee properties from the stored copy to one posted to the >>>> server for >>>> you to try out. >>>> >>>> (If there are any other properties that should also be 'carried >>>> over', let >>>> me know) >>>> >>>> Attendee is one of the properties currently not converted from/to, >>>> though >>>> Windows Mobile does support it. >>>> On 13/2/08 4:43 PM, "Samuli Seppänen" >>>> wrote: >>>> >>>>> Hi! >>>>> >>>>> >>>>> So, is there any calendar merging functionality in GroupDAV connector >>>>> yet? If so, where is it? If not, where should it be? >>>>> >>>>> Best regards, >>>>> >>>>> Samuli Seppänen >> > From groupdav@opengroupware.org Wed Feb 20 10:27:27 2008 From: groupdav@opengroupware.org (Mathew McBride) Date: Wed, 20 Feb 2008 21:27:27 +1100 Subject: [GroupDAV] Funambol GroupDAV connector: OGo ATTENDEE fields get stripped away In-Reply-To: <47BAF9B1.1000506@tietoteema.fi> Message-ID: Silly me, I mistyped '0' instead of 'i' in InboundFunambolCalendarObject.java, line 239 and 252. Change them and the attendees copy properly. A proper merge to cover any attributes not touched on the device is on the todo list as well. Another thing, ZideStore still seems to have a bug where a bad MAILTO: will be given when a contact has no email address entered. On 20/2/08 2:45 AM, "Samuli Sepp=E4nen" wrote= : > I got the new connector version installed and tested to see if the > ATTENDEE problem was still present. It seems that it works but not the > way it's supposed: >=20 > SUMMARY:OGo ATTENDEE test > LOCATION:Changed in Nokia > ATTENDEE;CUTYPE=3DINDIVIDUAL;PARTSTAT=3DNEEDS-ACTION;ROLE=3DREQ-PARTICIPANT;RSV= P=3DFAL > SE;CN=3DSamuli=20 > Sepp=E4nen:MAILTO:samuli.seppanen@tietoteema.fi > ATTENDEE;CUTYPE=3DINDIVIDUAL;PARTSTAT=3DNEEDS-ACTION;ROLE=3DREQ-PARTICIPANT;RSV= P=3DFAL > SE;CN=3DSamuli=20 > Sepp=E4nen:MAILTO:samuli.seppanen@tietoteema.fi > ATTENDEE;CUTYPE=3DINDIVIDUAL;PARTSTAT=3DNEEDS-ACTION;ROLE=3DREQ-PARTICIPANT;RSV= P=3DFAL > SE;CN=3DSamuli=20 > Sepp=E4nen:MAILTO:samuli.seppanen@tietoteema.fi > ORGANIZER;CN=3DSamuli Sepp=E4nen:MAILTO:samuli.seppanen@tietoteema.fi >=20 > This event had three participants, but it seems that the first ATTENDEE > is fetched three times, instead of each participant one time. Do you > have a quick fix for this or shall I dig into the sources more deeply? >=20 > Best regards, >=20 > Samuli >=20 >=20 >> I believe that OGo uses the ORGANIZER field too. I checked out the >> latest connector version and will test it tomorrow. I'll report on how >> it works. >>=20 >> Btw. I'll be pushing my updated "Nokia S60 <-> Funambol 6.5 <-> GroupDAV >> connector 2 <-> OGo 1.1.7" sync documentation to the OGo documentation >> plone in a few weeks, so stay tuned :) >>=20 >> Samuli >>=20 >>=20 >>> Code is now in git ( >>> http://repo.or.cz/w/funambol-groupdav-connector.git ). >>> I've also carried over ORGANIZER for the benefit of Citadel users. >>>=20 >>>=20 >>> On 13/2/08 7:58 PM, "Samuli Sepp=E4nen" >>> wrote: >>>=20 >>>> Ok, great! I'll see if there are any other Zidestore properties that >>>> cause problems. If you fix the ATTENDEE issue I can most likely fix th= e >>>> rest of the property problems myself and send a patch. >>>>=20 >>>> Samuli >>>>=20 >>>>> Not at the moment. It can be added quite easily. I'll add some code >>>>> to carry >>>>> the attendee properties from the stored copy to one posted to the >>>>> server for >>>>> you to try out. >>>>>=20 >>>>> (If there are any other properties that should also be 'carried >>>>> over', let >>>>> me know) >>>>>=20 >>>>> Attendee is one of the properties currently not converted from/to, >>>>> though >>>>> Windows Mobile does support it. >>>>> On 13/2/08 4:43 PM, "Samuli Sepp=E4nen" >>>>> wrote: >>>>>=20 >>>>>> Hi! >>>>>>=20 >>>>>>=20 >>>>>> So, is there any calendar merging functionality in GroupDAV connecto= r >>>>>> yet? If so, where is it? If not, where should it be? >>>>>>=20 >>>>>> Best regards, >>>>>>=20 >>>>>> Samuli Sepp=E4nen >>>=20 >>=20 From groupdav@opengroupware.org Wed Feb 20 16:20:36 2008 From: groupdav@opengroupware.org (=?ISO-8859-1?Q?Samuli_Sepp=E4nen?=) Date: Wed, 20 Feb 2008 18:20:36 +0200 Subject: [GroupDAV] Funambol GroupDAV connector: OGo ATTENDEE fields get stripped away In-Reply-To: References: Message-ID: <47BC5354.6090607@tietoteema.fi> I thought that's what had happened :). Thanks for the info, I'll try the fix first thing tomorrow. Conserning Zidestore... I haven't noticed the bug you mentioned, but I'm sure it has it's laundry list of bugs like OGo webui. I noticed that ical4j dies if Zidestore serves an email address containing scandinavian characters. Of course Zidestore shouldn't do that, but it does. Samuli > Silly me, I mistyped '0' instead of 'i' in > InboundFunambolCalendarObject.java, line 239 and 252. Change them and the > attendees copy properly. > > A proper merge to cover any attributes not touched on the device is on the > todo list as well. > > Another thing, ZideStore still seems to have a bug where a bad MAILTO: will > be given when a contact has no email address entered. > > > On 20/2/08 2:45 AM, "Samuli Seppänen" wrote: > >> I got the new connector version installed and tested to see if the >> ATTENDEE problem was still present. It seems that it works but not the >> way it's supposed: >> >> SUMMARY:OGo ATTENDEE test >> LOCATION:Changed in Nokia >> ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=FAL >> SE;CN=Samuli >> Seppänen:MAILTO:samuli.seppanen@tietoteema.fi >> ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=FAL >> SE;CN=Samuli >> Seppänen:MAILTO:samuli.seppanen@tietoteema.fi >> ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=FAL >> SE;CN=Samuli >> Seppänen:MAILTO:samuli.seppanen@tietoteema.fi >> ORGANIZER;CN=Samuli Seppänen:MAILTO:samuli.seppanen@tietoteema.fi >> >> This event had three participants, but it seems that the first ATTENDEE >> is fetched three times, instead of each participant one time. Do you >> have a quick fix for this or shall I dig into the sources more deeply? >> >> Best regards, >> >> Samuli >> >> >>> I believe that OGo uses the ORGANIZER field too. I checked out the >>> latest connector version and will test it tomorrow. I'll report on how >>> it works. >>> >>> Btw. I'll be pushing my updated "Nokia S60 <-> Funambol 6.5 <-> GroupDAV >>> connector 2 <-> OGo 1.1.7" sync documentation to the OGo documentation >>> plone in a few weeks, so stay tuned :) >>> >>> Samuli >>> >>> >>>> Code is now in git ( >>>> http://repo.or.cz/w/funambol-groupdav-connector.git ). >>>> I've also carried over ORGANIZER for the benefit of Citadel users. >>>> >>>> >>>> On 13/2/08 7:58 PM, "Samuli Seppänen" >>>> wrote: >>>> >>>>> Ok, great! I'll see if there are any other Zidestore properties that >>>>> cause problems. If you fix the ATTENDEE issue I can most likely fix the >>>>> rest of the property problems myself and send a patch. >>>>> >>>>> Samuli >>>>> >>>>>> Not at the moment. It can be added quite easily. I'll add some code >>>>>> to carry >>>>>> the attendee properties from the stored copy to one posted to the >>>>>> server for >>>>>> you to try out. >>>>>> >>>>>> (If there are any other properties that should also be 'carried >>>>>> over', let >>>>>> me know) >>>>>> >>>>>> Attendee is one of the properties currently not converted from/to, >>>>>> though >>>>>> Windows Mobile does support it. >>>>>> On 13/2/08 4:43 PM, "Samuli Seppänen" >>>>>> wrote: >>>>>> >>>>>>> Hi! >>>>>>> >>>>>>> >>>>>>> So, is there any calendar merging functionality in GroupDAV connector >>>>>>> yet? If so, where is it? If not, where should it be? >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Samuli Seppänen > From groupdav@opengroupware.org Wed Feb 20 16:38:31 2008 From: groupdav@opengroupware.org (Helge Hess) Date: Wed, 20 Feb 2008 17:38:31 +0100 Subject: [GroupDAV] Funambol GroupDAV connector: OGo ATTENDEE fields get stripped away In-Reply-To: <47BC5354.6090607@tietoteema.fi> References: <47BC5354.6090607@tietoteema.fi> Message-ID: <9C0DAFF6-DE92-4BF0-B572-ED5057BC31A3@opengroupware.org> On 20.02.2008, at 17:20, Samuli Sepp=E4nen wrote: > I noticed that ical4j dies if Zidestore serves an email address =20 > containing scandinavian characters. Of course Zidestore shouldn't do =20= > that, but it does. Could you elaborate? Eg: >> ATTENDEE;CUTYPE=3DINDIVIDUAL;PARTSTAT=3DNEEDS-ACTION;ROLE=3DREQ-=20 >> PARTICIPANT;RSVP=3DFAL >> SE;CN=3DSamuli Sepp=E4nen:MAILTO:samuli.seppanen@tietoteema.fi Looks fine to me? (iCal content is UTF-8). Thanks, Helge --=20 Helge Hess http://www.helgehess.eu/= From groupdav@opengroupware.org Wed Feb 20 22:54:28 2008 From: groupdav@opengroupware.org (Benjamin Long) Date: Wed, 20 Feb 2008 17:54:28 -0500 Subject: [GroupDAV] Alarms in Funambol Calendar Sync Message-ID: <200802201754.28833.bflong@longbros.com> Matt, all, Is there a way to get alarm events to sync with the Synthesis client? Calendar syncing seems to work GREAT, but alarms are not synced back and forth, although they do seem to be preserved. If someone creates a event on the server and sets an alarm, they expect to be able to sync the event and have the alarm set on the palm. The only other issue holding back a rollout is task syncing. I've got more log spelunking to do on that one. I'll make a separate email about it. ;) In all it's gotten much, much faster since the last time I tried it. Thanks for the work Matt! Benjamin Long From groupdav@opengroupware.org Thu Feb 21 06:20:38 2008 From: groupdav@opengroupware.org (Mathew McBride) Date: Thu, 21 Feb 2008 17:20:38 +1100 Subject: [GroupDAV] Alarms in Funambol Calendar Sync In-Reply-To: <200802201754.28833.bflong@longbros.com> Message-ID: Alarms should not be transmitted back and forth to the server per the GroupDAV spec, but it can be done. I'll get back to you with an 'alarm-enabled version'. Its another thing that will need some merge code like the organizer properties too. I'm also looking for comments on how alarms could be retained by the connector (not sent to server) as some would need them for backup. I'll probably have them stored in a .properties file in the store dir On 21/2/08 9:54 AM, "Benjamin Long" wrote: > Matt, all, > > Is there a way to get alarm events to sync with the Synthesis client? > Calendar syncing seems to work GREAT, but alarms are not synced back and > forth, although they do seem to be preserved. If someone creates a event on > the server and sets an alarm, they expect to be able to sync the event and > have the alarm set on the palm. > > The only other issue holding back a rollout is task syncing. I've got more > log spelunking to do on that one. I'll make a separate email about it. ;) > > In all it's gotten much, much faster since the last time I tried it. Thanks > for the work Matt! > > Benjamin Long From groupdav@opengroupware.org Thu Feb 21 12:49:48 2008 From: groupdav@opengroupware.org (Helge Hess) Date: Thu, 21 Feb 2008 13:49:48 +0100 Subject: [GroupDAV] Alarms in Funambol Calendar Sync In-Reply-To: References: Message-ID: <09722372-84F2-4E95-8244-F5A4D5EC9DAB@opengroupware.org> On 21.02.2008, at 07:20, Mathew McBride wrote: > Alarms should not be transmitted back and forth to the server per the > GroupDAV spec, but it can be done. I'll get back to you with an > 'alarm-enabled version'. Its another thing that will need some merge > code > like the organizer properties too. I guess that should be a user configurable setting. Some people want all their devices ring, some don't ;-) IMHO reminders belong on the specific client (eg I'm always annoyed if my iCal.app reminds me, and then a few seconds later the iPhone goes off, sigh). Syncing reminders to group folders is quite problematic, since in servers they are usually per-event, not per-user. Hence, if someone sets a reminder at -30min, it will potentially go off for the whole company! Greets, Helge -- Helge Hess http://www.helgehess.eu/ From groupdav@opengroupware.org Sun Feb 24 06:26:38 2008 From: groupdav@opengroupware.org (Mathew McBride) Date: Sun, 24 Feb 2008 17:26:38 +1100 Subject: [GroupDAV] Building GroupDAV connector In-Reply-To: <47A3178A.7020104@tietoteema.fi> Message-ID: An update re the build system: I'm considering moving the build system to Maven which should make the build process for others much easier given the number of external dependencies we have. Funambol builds using Maven too which is a positive. There is now a rudimentary optional alarm implementation in git. Funambol only gives me display alarms to work with so any audio alarms will be ignored. (This isn't an issue on my Treo 600 where Synthesis will create an audio alarm anyway). There is merge code to retain any alarms on the server, and if anyone needs to lock down alarm circulation to certain spaces (i.e personal events only), they can do so in the future by overriding a method in the connector. From groupdav@opengroupware.org Mon Feb 25 10:02:36 2008 From: groupdav@opengroupware.org (=?ISO-8859-1?Q?Samuli_Sepp=E4nen?=) Date: Mon, 25 Feb 2008 12:02:36 +0200 Subject: [GroupDAV] Funambol GroupDAV connector: OGo ATTENDEE fields get stripped away In-Reply-To: <9C0DAFF6-DE92-4BF0-B572-ED5057BC31A3@opengroupware.org> References: <47BC5354.6090607@tietoteema.fi> <9C0DAFF6-DE92-4BF0-B572-ED5057BC31A3@opengroupware.org> Message-ID: <47C2923C.6050000@tietoteema.fi> >> I noticed that ical4j dies if Zidestore serves an email address >> containing scandinavian characters. Of course Zidestore shouldn't do >> that, but it does. > Could you elaborate? Of course. I had a OGo user which had email "äksy@tietoteema.fi" as a participant in an event. The corresponding ATTENDEE line probably looked like this: ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=FAL SE;CN=Testi Henkilö:MAILTO:testi.henkilö@tietoteema.fi In addition the scandinavian character in the email and CN seemed to be encoded in ISO-8859-1, not UTF-8. Whether the reason was the "ä" in the email address or the ISO-8859-1 encoding, ical4j died with an exception during OGo<->Nokia sync. Removing the entire event from OGo fixed the sync issue. Probably just removing the offending user from the event would have worked as well. Samuli From groupdav@opengroupware.org Mon Feb 25 10:04:54 2008 From: groupdav@opengroupware.org (=?ISO-8859-1?Q?Samuli_Sepp=E4nen?=) Date: Mon, 25 Feb 2008 12:04:54 +0200 Subject: [GroupDAV] Funambol GroupDAV connector: OGo ATTENDEE fields get stripped away In-Reply-To: References: Message-ID: <47C292C6.9040707@tietoteema.fi> I installed and tested this simple patch and it seemd to work just fine. Thanks, Matt Samuli > Silly me, I mistyped '0' instead of 'i' in > InboundFunambolCalendarObject.java, line 239 and 252. Change them and the > attendees copy properly. > > A proper merge to cover any attributes not touched on the device is on the > todo list as well. > > Another thing, ZideStore still seems to have a bug where a bad MAILTO: will > be given when a contact has no email address entered. > > > On 20/2/08 2:45 AM, "Samuli Seppänen" wrote: > >> I got the new connector version installed and tested to see if the >> ATTENDEE problem was still present. It seems that it works but not the >> way it's supposed: >> >> SUMMARY:OGo ATTENDEE test >> LOCATION:Changed in Nokia >> ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=FAL >> SE;CN=Samuli >> Seppänen:MAILTO:samuli.seppanen@tietoteema.fi >> ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=FAL >> SE;CN=Samuli >> Seppänen:MAILTO:samuli.seppanen@tietoteema.fi >> ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=FAL >> SE;CN=Samuli >> Seppänen:MAILTO:samuli.seppanen@tietoteema.fi >> ORGANIZER;CN=Samuli Seppänen:MAILTO:samuli.seppanen@tietoteema.fi >> >> This event had three participants, but it seems that the first ATTENDEE >> is fetched three times, instead of each participant one time. Do you >> have a quick fix for this or shall I dig into the sources more deeply? >> >> Best regards, >> >> Samuli >> >> >>> I believe that OGo uses the ORGANIZER field too. I checked out the >>> latest connector version and will test it tomorrow. I'll report on how >>> it works. >>> >>> Btw. I'll be pushing my updated "Nokia S60 <-> Funambol 6.5 <-> GroupDAV >>> connector 2 <-> OGo 1.1.7" sync documentation to the OGo documentation >>> plone in a few weeks, so stay tuned :) >>> >>> Samuli >>> >>> >>>> Code is now in git ( >>>> http://repo.or.cz/w/funambol-groupdav-connector.git ). >>>> I've also carried over ORGANIZER for the benefit of Citadel users. >>>> >>>> >>>> On 13/2/08 7:58 PM, "Samuli Seppänen" >>>> wrote: >>>> >>>>> Ok, great! I'll see if there are any other Zidestore properties that >>>>> cause problems. If you fix the ATTENDEE issue I can most likely fix the >>>>> rest of the property problems myself and send a patch. >>>>> >>>>> Samuli >>>>> >>>>>> Not at the moment. It can be added quite easily. I'll add some code >>>>>> to carry >>>>>> the attendee properties from the stored copy to one posted to the >>>>>> server for >>>>>> you to try out. >>>>>> >>>>>> (If there are any other properties that should also be 'carried >>>>>> over', let >>>>>> me know) >>>>>> >>>>>> Attendee is one of the properties currently not converted from/to, >>>>>> though >>>>>> Windows Mobile does support it. >>>>>> On 13/2/08 4:43 PM, "Samuli Seppänen" >>>>>> wrote: >>>>>> >>>>>>> Hi! >>>>>>> >>>>>>> >>>>>>> So, is there any calendar merging functionality in GroupDAV connector >>>>>>> yet? If so, where is it? If not, where should it be? >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Samuli Seppänen > From groupdav@opengroupware.org Mon Feb 25 11:09:14 2008 From: groupdav@opengroupware.org (Helge Hess) Date: Mon, 25 Feb 2008 12:09:14 +0100 Subject: [GroupDAV] Funambol GroupDAV connector: OGo ATTENDEE fields get stripped away In-Reply-To: <47C2923C.6050000@tietoteema.fi> References: <47BC5354.6090607@tietoteema.fi> <9C0DAFF6-DE92-4BF0-B572-ED5057BC31A3@opengroupware.org> <47C2923C.6050000@tietoteema.fi> Message-ID: On 25.02.2008, at 11:02, Samuli Sepp=E4nen wrote: >>> I noticed that ical4j dies if Zidestore serves an email address =20 >>> containing scandinavian characters. Of course Zidestore shouldn't =20= >>> do that, but it does. >> Could you elaborate? > > Of course. I had a OGo user which had email "=E4ksy@tietoteema.fi" as = a > participant in an event. The corresponding ATTENDEE line probably =20 > looked like this: > > ATTENDEE;CUTYPE=3DINDIVIDUAL;PARTSTAT=3DNEEDS-ACTION;ROLE=3DREQ-=20 > PARTICIPANT;RSVP=3DFAL > SE;CN=3DTesti Henkil=F6:MAILTO:testi.henkil=F6@tietoteema.fi OK, just had a look on how iCal.app encodes it: ---snip--- ATTENDEE;CN=3D"John = =DCml=E4ut";CUTYPE=3DINDIVIDUAL;ROLE=3DREQ-PARTICIPANT:mailto: testi.henkil%C3%B6@tietoteema.fi ---snap--- Looks like we need to encode the email address but keep the CN. > In addition the scandinavian character in the email and CN seemed to =20= > be encoded in ISO-8859-1, not UTF-8. That would be wrong in any case (though I'm a bit surprised). > Whether the reason was the "=E4" in the email address or the =20 > ISO-8859-1 encoding, ical4j died with an exception during OGo<-=20 > >Nokia sync. Which is still strange. It shouldn't crash but 'just' show b0rked =20 characters? Thanks, Helge --=20 Helge Hess http://www.helgehess.eu/= From groupdav@opengroupware.org Mon Feb 25 11:54:21 2008 From: groupdav@opengroupware.org (=?ISO-8859-1?Q?Samuli_Sepp=E4nen?=) Date: Mon, 25 Feb 2008 13:54:21 +0200 Subject: [GroupDAV] Funambol GroupDAV connector: OGo ATTENDEE fields get stripped away In-Reply-To: References: <47BC5354.6090607@tietoteema.fi> <9C0DAFF6-DE92-4BF0-B572-ED5057BC31A3@opengroupware.org> <47C2923C.6050000@tietoteema.fi> Message-ID: <47C2AC6D.7000609@tietoteema.fi> >>>> I noticed that ical4j dies if Zidestore serves an email address >>>> containing scandinavian characters. Of course Zidestore shouldn't do >>>> that, but it does. >>> Could you elaborate? >> >> Of course. I had a OGo user which had email "äksy@tietoteema.fi" as a >> participant in an event. The corresponding ATTENDEE line probably >> looked like this: >> >> ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=FAL >> >> SE;CN=Testi Henkilö:MAILTO:testi.henkilö@tietoteema.fi > > OK, just had a look on how iCal.app encodes it: > ---snip--- > ATTENDEE;CN="John Ümläut";CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT:mailto: > testi.henkil%C3%B6@tietoteema.fi > ---snap--- > Looks like we need to encode the email address but keep the CN. Shouldn't email addresses be plain ASCII only? If so, there's no need to fix this... >> In addition the scandinavian character in the email and CN seemed to >> be encoded in ISO-8859-1, not UTF-8. > > That would be wrong in any case (though I'm a bit surprised). Our OGo database has a long history behind it, so I'm not surprised at all :). Our users authenticate from LDAP and it's quite possible that the invalid email address came from there. >> Whether the reason was the "ä" in the email address or the ISO-8859-1 >> encoding, ical4j died with an exception during OGo<->Nokia sync. > Which is still strange. It shouldn't crash but 'just' show b0rked > characters? The exception was probably caused by VCALENDAR property -> ical4j property converter, but I can't remember exactly where. Samuli From groupdav@opengroupware.org Mon Feb 25 13:46:45 2008 From: groupdav@opengroupware.org (Adam Tauno Williams) Date: Mon, 25 Feb 2008 08:46:45 -0500 Subject: [GroupDAV] Funambol GroupDAV connector: OGo ATTENDEE fields get stripped away In-Reply-To: <47C2AC6D.7000609@tietoteema.fi> References: <47BC5354.6090607@tietoteema.fi> <9C0DAFF6-DE92-4BF0-B572-ED5057BC31A3@opengroupware.org> <47C2923C.6050000@tietoteema.fi> <47C2AC6D.7000609@tietoteema.fi> Message-ID: <1203947205.5704.6.camel@WM_ADAM1.morrison.iserv.net> --=-pqHD0aXbUhpTb8CagBj/ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > >>>> I noticed that ical4j dies if Zidestore serves an email address=20 > >>>> containing scandinavian characters. Of course Zidestore shouldn't do= =20 > >>>> that, but it does. > >>> Could you elaborate? > >> Of course. I had a OGo user which had email "=C3=A4ksy@tietoteema.fi" = as a > >> participant in an event. The corresponding ATTENDEE line probably=20 > >> looked like this: > >> ATTENDEE;CUTYPE=3DINDIVIDUAL;PARTSTAT=3DNEEDS-ACTION;ROLE=3DREQ-PARTIC= IPANT;RSVP=3DFAL=20 > >> SE;CN=3DTesti Henkil=C3=B6:MAILTO:testi.henkil=C3=B6@tietoteema.fi > > OK, just had a look on how iCal.app encodes it: > > ---snip--- > > ATTENDEE;CN=3D"John =C3=9Cml=C3=A4ut";CUTYPE=3DINDIVIDUAL;ROLE=3DREQ-PA= RTICIPANT:mailto: > > testi.henkil%C3%B6@tietoteema.fi > > ---snap--- > > Looks like we need to encode the email address but keep the CN. > Shouldn't email addresses be plain ASCII only?=20 Yes. RFC2822 section 3.4.1. I just had this argument with someone about something else. But since non-ASCII DNS is now allowd, I'm not certain how that should work. But I suppose that is a separate, not really GROUPDAV, issue. > >> In addition the scandinavian character in the email and CN seemed to=20 > >> be encoded in ISO-8859-1, not UTF-8. > > That would be wrong in any case (though I'm a bit surprised). > Our OGo database has a long history behind it, so I'm not surprised at=20 > all :). Our users authenticate from LDAP and it's quite possible that=20 > the invalid email address came from there. Have you converted your database from from LATIN-1 to UTF-8 (really an OGo-Users@ and not a GroupDAV one)? --=20 Adam Tauno Williams --=-pqHD0aXbUhpTb8CagBj/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBHwsbFLRePpNle04MRAmFzAJ0W5996n9S7ACbG7UZMAu2v/mjGDACcDXVA Wl7CESqP7ZMHtGNkDSh/fNg= =Hcmm -----END PGP SIGNATURE----- --=-pqHD0aXbUhpTb8CagBj/-- From groupdav@opengroupware.org Mon Feb 25 23:15:23 2008 From: groupdav@opengroupware.org (Wolfgang Sourdeau) Date: Mon, 25 Feb 2008 18:15:23 -0500 Subject: [GroupDAV] ANN: SOGo Connector v0.66 Message-ID: <235c-47c34c00-1f-b73abaf0@94558132> The Inverse Team is pleased to announce the 0.66 release of the "SOGo Connector" extension for Thunderbird. === What is the SOGo Connector === This extension transforms Thunderbird into a full DAV client for groupware servers such as SOGo, OpenGroupware.org or Citadel. It does this by adding support for remote DAV address books and by adding features to be used along with the Lightning calendar extension. More information can be found on our website : http://www.inverse.ca/contributions/sogo_connector.html === What is SOGo === SOGo is a free and modern scalable groupware server. It offers shared calendars, address books and emails through your favorite Web browser or by using a native client such as Mozilla Thunderbird and Lightning. SOGo is standard-compliant and supports CalDAV, CardDAV, GroupDAV and reuses existing IMAP, SMTP and database servers - making the solution easy to deploy and interoperable with many applications. SOGo features : * Scalable architecture suitable for deployments from dozen to many thousand users * Rich Web-based interface that shares the look and feel, the features and the data of Mozilla Thunderbird and Lightning * Improved integration with Mozilla Thunderbird and Lighthing by using the SOGo Connector * Two-way synchronization support with any SyncML-capable devices (BlackBerry, Palm, Windows CE, etc.) by using the Funambol SOGo Connector and many more! SOGo and our connectors are completely free. We have a demo website where you can experience SOGo from the Web or your preferred CalDAV client: http://sogo-demo.inverse.ca/ === Changes since the last release === * rewrite of the CardDAV addressbook implementation: * fixes the situation where one was not able to write to a mailing list * fixes the duplicate entries for such addressbooks * fixes the autocompletion working only one time per two tries * improved the performance and the reliability of the freebusy resolution in the attendees window * added a hook to give up the startup process to the SOGo Integrator if present === Getting the SOGo Connector === SOGo Connector is free software and is distributed under the GNU GPL v. 2. As such, you are free to download and use it from : http://www.inverse.ca/groupware/plugins/sogo-connector-0.66.xpi Documentation about the installation and configuration of SOGo is available from : http://www.inverse.ca/contributions/sogo_connector.html === Getting support === For any questions, do not hesitate to contact us by writing an email to : support@inverse.ca Inverse offers professional services around SOGo to help organizations deploy the solution and migrate from their legacy systems. From groupdav@opengroupware.org Mon Feb 25 23:17:09 2008 From: groupdav@opengroupware.org (Wolfgang Sourdeau) Date: Mon, 25 Feb 2008 18:17:09 -0500 Subject: [GroupDAV] ANN: SOGo Integrator v0.66 Message-ID: <235c-47c34c80-2b-b73abaf0@167626676> The Inverse Team is pleased to announce the first release of the "SOGo Integrator" extension for Thunderbird to the general public. === What is the SOGo Integrator === This extension transforms Thunderbird in a pure "heavy" client for SOGo. Whereas the SOGo Connector is meant for portability ("horizontal integration"), the SOGo Integrator makes use of the features and layout of SOGo only ("vertical integration"). With this, it achieves the following: * remote administration of folder subscriptions * an automatic replication of your local and subscribed folders * when correctly setup, it handles the propagation of updates to chosen extensions from a local update server * automatic propagation of default settings More information can be found on our website : http://www.inverse.ca/contributions/sogo_integrator.html === What is SOGo === SOGo is a free and modern scalable groupware server. It offers shared calendars, address books and emails through your favorite Web browser or by using a native client such as Mozilla Thunderbird and Lightning. SOGo is standard-compliant and supports CalDAV, CardDAV, GroupDAV and reuses existing IMAP, SMTP and database servers - making the solution easy to deploy and interoperable with many applications. SOGo features : * Scalable architecture suitable for deployments from dozen to many thousand users * Rich Web-based interface that shares the look and feel, the features and the data of Mozilla Thunderbird and Lightning * Improved integration with Mozilla Thunderbird and Lightning by using the SOGo Connector and SOGo Integrator extensions * Two-way synchronization support with any SyncML-capable devices (BlackBerry, Palm, Windows CE, etc.) by using the Funambol SOGo Connector and many more! SOGo and our extensions are completely free. We have a demo website where you can experience SOGo from the Web or your preferred CalDAV client: http://sogo-demo.inverse.ca/ === Changes since the last release === * implemented interfaces to handle ACL on SOGo addressbooks and calendars === Getting the SOGo Integrator === SOGo Integrator is free software and is distributed under the GNU GPL v. 2. As such, you are free to download and use it from : http://sogo-demo.inverse.ca/plugins/sogo-integrator-0.66-sogo-demo.xpi This version is configured to connect to the SOGo instance running on our demo website. Since your personal addressbook will be automatically uploaded to the server, your are strongly recommended to use a dedicated user profile for testing. To achieve this, run Thunderbird with the "-ProfileManager" parameter. Once this is done, specify "sogo1", "sogo2" or "sogo3" as your username to connect to the mail server. You can specify sogo-demo.inverse.ca as the IMAP mail server but you will not be able to connect. To avoid annoying warning messages, disable the automatic mail checking in your account settings. Documentation about the installation and configuration of the SOGo integrator is available from : http://www.inverse.ca/contributions/sogo_integrator.html === Getting support === For any questions, do not hesitate to contact us by writing an email to : support@inverse.ca Inverse offers professional services around SOGo to help organizations deploy the solution and migrate from their legacy systems. From groupdav@opengroupware.org Tue Feb 26 11:12:32 2008 From: groupdav@opengroupware.org (Mathew McBride) Date: Tue, 26 Feb 2008 22:12:32 +1100 Subject: [GroupDAV] Alarms in Funambol Calendar Sync In-Reply-To: <200802201754.28833.bflong@longbros.com> Message-ID: Here is the latest test release: http://latest.bionicmessage.net/groupdav-2.0-26feb08.s4j - Alarm conversion option added. Only supports DISPLAY reminders, alarms relative due to DTSTART due to Funambol and vcal1 limitations. Will try to retain ical2 alarms that don't fall in to these / not enabled, but I haven't tested that extensively. (Conversion tested with Korganizer<->Synthesis and old Treo, your mileage may vary with newer palm devices/other OS)* - Fixed the attendee/organizer carry over typo. - Fixed malformed GET path bug - Also new since the 2.0 release is the ability to sync Calendar/Task at once with S60 devices, which don't have separate sync sources for each. See page 7 of the updated docs: http://www.scribd.com/doc/2075972/bionicmessage-Groupware-Sync-Server-instal lconfig-guide * Known issue: ical4j may blow up when one specifies a path to an audio reminder (Korganizer) On 21/2/08 9:54 AM, "Benjamin Long" wrote: > Matt, all, > > Is there a way to get alarm events to sync with the Synthesis client? > Calendar syncing seems to work GREAT, but alarms are not synced back and > forth, although they do seem to be preserved. If someone creates a event on > the server and sets an alarm, they expect to be able to sync the event and > have the alarm set on the palm. > > The only other issue holding back a rollout is task syncing. I've got more > log spelunking to do on that one. I'll make a separate email about it. ;) > > In all it's gotten much, much faster since the last time I tried it. Thanks > for the work Matt! > > Benjamin Long From groupdav@opengroupware.org Tue Feb 26 14:50:47 2008 From: groupdav@opengroupware.org (=?UTF-8?B?U2FtdWxpIFNlcHDDpG5lbg==?=) Date: Tue, 26 Feb 2008 16:50:47 +0200 Subject: [GroupDAV] Funambol GroupDAV connector: OGo ATTENDEE fields get stripped away In-Reply-To: <1203947205.5704.6.camel@WM_ADAM1.morrison.iserv.net> References: <47BC5354.6090607@tietoteema.fi> <9C0DAFF6-DE92-4BF0-B572-ED5057BC31A3@opengroupware.org> <47C2923C.6050000@tietoteema.fi> <47C2AC6D.7000609@tietoteema.fi> <1203947205.5704.6.camel@WM_ADAM1.morrison.iserv.net> Message-ID: <47C42747.7050103@tietoteema.fi> Adam Tauno Williams ha scritto: >>>>>> I noticed that ical4j dies if Zidestore serves an email address >>>>>> containing scandinavian characters. Of course Zidestore shouldn't do >>>>>> that, but it does. >>>>> Could you elaborate? >>>> Of course. I had a OGo user which had email "äksy@tietoteema.fi" as a >>>> participant in an event. The corresponding ATTENDEE line probably >>>> looked like this: >>>> ATTENDEE;CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=FAL >>>> SE;CN=Testi Henkilö:MAILTO:testi.henkilö@tietoteema.fi >>> OK, just had a look on how iCal.app encodes it: >>> ---snip--- >>> ATTENDEE;CN="John Ãœmläut";CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT:mailto: >>> testi.henkil%C3%B6@tietoteema.fi >>> ---snap--- >>> Looks like we need to encode the email address but keep the CN. >> Shouldn't email addresses be plain ASCII only? > > Yes. RFC2822 section 3.4.1. I just had this argument with someone > about something else. But since non-ASCII DNS is now allowd, I'm not > certain how that should work. But I suppose that is a separate, not > really GROUPDAV, issue. Yep. No need to worry about this (for a while). >>>> In addition the scandinavian character in the email and CN seemed to >>>> be encoded in ISO-8859-1, not UTF-8. >>> That would be wrong in any case (though I'm a bit surprised). >> Our OGo database has a long history behind it, so I'm not surprised at >> all :). Our users authenticate from LDAP and it's quite possible that >> the invalid email address came from there. > > Have you converted your database from from LATIN-1 to UTF-8 (really an > OGo-Users@ and not a GroupDAV one)? At OGo 1.0.0 -> 1.1.7 upgrade, yes. Samuli From groupdav@opengroupware.org Tue Feb 26 15:17:00 2008 From: groupdav@opengroupware.org (=?ISO-8859-15?Q?Samuli_Sepp=E4nen?=) Date: Tue, 26 Feb 2008 17:17:00 +0200 Subject: [GroupDAV] Synclet-type converters for various GroupDAV servers? Message-ID: <47C42D6C.9050108@tietoteema.fi> Hi! I just encountered a problem with GroupDAV connector, OGo and Nokia sync. The exact problem is not relevant, I can fix it, but it gave me an idea... First of all, I've noticed that every backend server (OGo, Exchange, whatever) interprets VCALENDARS (VEVENTS, VTODO, etc.) differently. This is especially true with "special" events, such as recurring events, allday events and such. In addition, every (mobile) device acts differently. In some cases I've noticed that - First Funambol inbound synclet modifies the VCALENDAR - Next Funambol foundation modules modify the VCALENDAR - Next Funambol connector modifies the VCALENDAR - Backend server reads the VCALENDAR the way it sees fit The same goes the other way (from backend server to the device). As you can see, it can be really tough to get some of the special events through this in usable form. The way I see it, it's always most useful to do the modifications to the VCALENDARs _as late as possible_, so that they won't get modified again before reaching their destination. Now to the actual idea... How difficult would it be to create separate (VCALENDAR) converter classes for each backend server? Or implement the same code with Beanshell, like with Funambol synclets? User could then select server type (OGo 1.0/OGo 1.1.x/Citadel...) and the appropriate converter code would then be used automatically. GroupDAV connector's core code wouldn't then have to touch VCALENDAR content at all - everything would be handled by the server-specific code. This would make it much easier to integrate the GroupDAV connector with various backend servers - especially if the server-specific code was in Beanshell (=no need to compile the GroupDAV connector code). Please tell me what you think. Samuli From groupdav@opengroupware.org Wed Feb 27 09:09:05 2008 From: groupdav@opengroupware.org (Mathew McBride) Date: Wed, 27 Feb 2008 20:09:05 +1100 Subject: [GroupDAV] Synclet-type converters for various GroupDAV servers? In-Reply-To: <47C42D6C.9050108@tietoteema.fi> Message-ID: This is one of the reasons I designed the processing module to be user-extensible, breaking out the data conversion for different servers can be done in the same way. I might move the part of the processing module tha= t calls the converters into a separate, overridable function. One could then just copy funambol2ical4j/ical4j2funambol into their own class and customiz= e what happens. =20 At the moment 'customizing' the processing module requires one to create a Funambol module and a XML-serialized bean*, like what Funambol already does for just about everything. BeanShell was definitely on my mind at the time, and the glue to do this will come sometime soon. (*or modify the connector like I did with S60 todo sync last week) On 27/2/08 2:17 AM, "Samuli Sepp=E4nen" wrote= : >=20 > Now to the actual idea... How difficult would it be to create separate > (VCALENDAR) converter classes for each backend server? Or implement the > same code with Beanshell, like with Funambol synclets? User could then > select server type (OGo 1.0/OGo 1.1.x/Citadel...) and the appropriate > converter code would then be used automatically. GroupDAV connector's > core code wouldn't then have to touch VCALENDAR content at all - > everything would be handled by the server-specific code. >=20 > This would make it much easier to integrate the GroupDAV connector with > various backend servers - especially if the server-specific code was in > Beanshell (=3Dno need to compile the GroupDAV connector code). >=20 > Please tell me what you think. >=20 > Samuli From groupdav@opengroupware.org Wed Feb 27 21:16:38 2008 From: groupdav@opengroupware.org (Benjamin Long) Date: Wed, 27 Feb 2008 16:16:38 -0500 Subject: [GroupDAV] Alarms in Funambol Calendar Sync In-Reply-To: References: Message-ID: <200802271616.38985.bflong@longbros.com> Matt, Seems to be working great on my T|X! Thanks! I'll use it for a while and let you know if anything breaks. Also, Todo's are working now. Don't know what happened, but they sync both ways now. Thanks again! Benjamin Long On Tuesday 26 February 2008 6:12:32 am Mathew McBride wrote: > Here is the latest test release: > http://latest.bionicmessage.net/groupdav-2.0-26feb08.s4j > > - Alarm conversion option added. Only supports DISPLAY reminders, alarms > relative due to DTSTART due to Funambol and vcal1 limitations. Will try to > retain ical2 alarms that don't fall in to these / not enabled, but I > haven't tested that extensively. (Conversion tested with > Korganizer<->Synthesis and old Treo, your mileage may vary with newer palm > devices/other OS)* - Fixed the attendee/organizer carry over typo. > - Fixed malformed GET path bug > - Also new since the 2.0 release is the ability to sync Calendar/Task at > once with S60 devices, which don't have separate sync sources for each. See > page 7 of the updated docs: > http://www.scribd.com/doc/2075972/bionicmessage-Groupware-Sync-Server-insta >l lconfig-guide > > * Known issue: ical4j may blow up when one specifies a path to an audio > reminder (Korganizer) > > On 21/2/08 9:54 AM, "Benjamin Long" wrote: > > Matt, all, > > > > Is there a way to get alarm events to sync with the Synthesis client? > > Calendar syncing seems to work GREAT, but alarms are not synced back and > > forth, although they do seem to be preserved. If someone creates a event > > on the server and sets an alarm, they expect to be able to sync the event > > and have the alarm set on the palm. > > > > The only other issue holding back a rollout is task syncing. I've got > > more log spelunking to do on that one. I'll make a separate email about > > it. ;) > > > > In all it's gotten much, much faster since the last time I tried it. > > Thanks for the work Matt! > > > > Benjamin Long From groupdav@opengroupware.org Thu Feb 28 15:27:47 2008 From: groupdav@opengroupware.org (Topper Doggle) Date: Thu, 28 Feb 2008 15:27:47 +0000 Subject: [GroupDAV] Syncing Nokia N73 with Funambol / Opengroupware Message-ID: <46e8a990802280727hb3a3ccxb08f999abe363507@mail.gmail.com> Hi, I've had an OGo server for a long time, and recently decided to try and get sync working to my N73 smartphone. I'm not having much luck so far, but there is so much to configure I wonder if it might be a config error rather than a bug. I'm trying to get calendar sync to work for starters. I'm using the Funambol / GroupDAV bundle from bionicmessage. Sync source settings ================ Modified groupdav-cal-v with: GroupDAV Server: http://localhost:21000/ (Funambol is on the same server as OGo / Zidestore.) Default calendar source: /zidestore/dav/%USER%/public/Calendar/ OGo all day event handling: ticked. N73 settings (all under Tools -> Sync -> OGo (new source I created) ========== Applications->Calendar -> Remote database: groupdav-cal-s Connection settings: Server version: 1.2 Host address: http://my.public.address/funambol/ds Port: 8080 The phone tries connecting then reports "system error". The (slightly munged) Funambol log follows. Hope someone can assist. [2008-02-28 15:25:00,752] [funambol.transport.http] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [] [] [] Handling incoming request [2008-02-28 15:25:00,752] [funambol.transport.http] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [] [] [] Request URL: http://my.public.server:8080/funambol/ds [2008-02-28 15:25:00,752] [funambol.transport.http] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [] [] [] Requested sessionId: null [2008-02-28 15:25:03,062] [funambol.engine.pipeline] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [] [] [] Input processing stopped by com.funambol.foundation.synclet.BeanShellSynclet@8d41f2[script=com/funambol/server/engine/pipeline/phones-support/bsh/NokiaS60in.bsh,header=user-agent,pattern=Nokia SyncML HTTP Client] (reason: NokiaS60in Synclet finished) [2008-02-28 15:25:03,109] [funambol.handler] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] myuser/IMEI:mymungedimei logged in. [2008-02-28 15:25:03,316] [funambol.engine] [ERROR] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Error in processing the output message com.funambol.framework.core.Sync4jException: at com.funambol.foundation.synclet.BeanShellSynclet.getOutputSynclet(BeanShellSynclet.java:307) at com.funambol.foundation.synclet.BeanShellSynclet.postProcessMessage(BeanShellSynclet.java:146) at com.funambol.framework.engine.pipeline.PipelineManager.postProcessMessage(PipelineManager.java:179) at com.funambol.server.engine.SyncAdapter.processWBXMLMessage(SyncAdapter.java:350) at com.funambol.transport.http.server.LocalSyncHolder.processWBXMLMessage(LocalSyncHolder.java:118) at com.funambol.transport.http.server.Sync4jServlet.doPost(Sync4jServlet.java:380) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.funambol.transport.http.server.LogContextFilter.doFilter(LogContextFilter.java:115) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Unknown Source) Caused by: Parse error at line 154, column 1. Encountered: << at bsh.Parser.generateParseException(Unknown Source) at bsh.Parser.jj_consume_token(Unknown Source) at bsh.Parser.Block(Unknown Source) at bsh.Parser.MethodDeclaration(Unknown Source) at bsh.Parser.BlockStatement(Unknown Source) at bsh.Parser.Line(Unknown Source) at bsh.Interpreter.Line(Unknown Source) at bsh.Interpreter.eval(Unknown Source) at bsh.Interpreter.eval(Unknown Source) at com.funambol.foundation.synclet.BeanShellSynclet.evalOutputScript(BeanShellSynclet.java:342) at com.funambol.foundation.synclet.BeanShellSynclet.getOutputSynclet(BeanShellSynclet.java:303) ... 24 more Parse error at line 154, column 1. Encountered: << at bsh.Parser.generateParseException(Unknown Source) at bsh.Parser.jj_consume_token(Unknown Source) at bsh.Parser.Block(Unknown Source) at bsh.Parser.MethodDeclaration(Unknown Source) at bsh.Parser.BlockStatement(Unknown Source) at bsh.Parser.Line(Unknown Source) at bsh.Interpreter.Line(Unknown Source) at bsh.Interpreter.eval(Unknown Source) at bsh.Interpreter.eval(Unknown Source) at com.funambol.foundation.synclet.BeanShellSynclet.evalOutputScript(BeanShellSynclet.java:342) at com.funambol.foundation.synclet.BeanShellSynclet.getOutputSynclet(BeanShellSynclet.java:303) at com.funambol.foundation.synclet.BeanShellSynclet.postProcessMessage(BeanShellSynclet.java:146) at com.funambol.framework.engine.pipeline.PipelineManager.postProcessMessage(PipelineManager.java:179) at com.funambol.server.engine.SyncAdapter.processWBXMLMessage(SyncAdapter.java:350) at com.funambol.transport.http.server.LocalSyncHolder.processWBXMLMessage(LocalSyncHolder.java:118) at com.funambol.transport.http.server.Sync4jServlet.doPost(Sync4jServlet.java:380) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.funambol.transport.http.server.LogContextFilter.doFilter(LogContextFilter.java:115) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Unknown Source) [2008-02-28 15:25:03,321] [funambol.transport.http] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Request processed. [2008-02-28 15:25:04,111] [funambol.transport.http] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Handling incoming request [2008-02-28 15:25:04,112] [funambol.transport.http] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Request URL: http://my.public.server:8080/funambol/ds [2008-02-28 15:25:04,112] [funambol.transport.http] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Requested sessionId: 88E1D57AAB7FE6F0FAF93237413B3699 [2008-02-28 15:25:04,542] [funambol.engine.pipeline] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Input processing stopped by com.funambol.foundation.synclet.BeanShellSynclet@8d41f2[script=com/funambol/server/engine/pipeline/phones-support/bsh/NokiaS60in.bsh,header=user-agent,pattern=Nokia SyncML HTTP Client] (reason: NokiaS60in Synclet finished) [2008-02-28 15:25:04,548] [funambol.handler] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Handling mapping ... [2008-02-28 15:25:04,548] [funambol.handler] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Performing mapping ... [2008-02-28 15:25:04,626] [funambol.engine] [ERROR] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Error in processing the output message com.funambol.framework.core.Sync4jException: at com.funambol.foundation.synclet.BeanShellSynclet.getOutputSynclet(BeanShellSynclet.java:307) at com.funambol.foundation.synclet.BeanShellSynclet.postProcessMessage(BeanShellSynclet.java:146) at com.funambol.framework.engine.pipeline.PipelineManager.postProcessMessage(PipelineManager.java:179) at com.funambol.server.engine.SyncAdapter.processWBXMLMessage(SyncAdapter.java:350) at com.funambol.transport.http.server.LocalSyncHolder.processWBXMLMessage(LocalSyncHolder.java:118) at com.funambol.transport.http.server.Sync4jServlet.doPost(Sync4jServlet.java:380) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.funambol.transport.http.server.LogContextFilter.doFilter(LogContextFilter.java:115) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Unknown Source) Caused by: Parse error at line 154, column 1. Encountered: << at bsh.Parser.generateParseException(Unknown Source) at bsh.Parser.jj_consume_token(Unknown Source) at bsh.Parser.Block(Unknown Source) at bsh.Parser.MethodDeclaration(Unknown Source) at bsh.Parser.BlockStatement(Unknown Source) at bsh.Parser.Line(Unknown Source) at bsh.Interpreter.Line(Unknown Source) at bsh.Interpreter.eval(Unknown Source) at bsh.Interpreter.eval(Unknown Source) at com.funambol.foundation.synclet.BeanShellSynclet.evalOutputScript(BeanShellSynclet.java:342) at com.funambol.foundation.synclet.BeanShellSynclet.getOutputSynclet(BeanShellSynclet.java:303) ... 24 more Parse error at line 154, column 1. Encountered: << at bsh.Parser.generateParseException(Unknown Source) at bsh.Parser.jj_consume_token(Unknown Source) at bsh.Parser.Block(Unknown Source) at bsh.Parser.MethodDeclaration(Unknown Source) at bsh.Parser.BlockStatement(Unknown Source) at bsh.Parser.Line(Unknown Source) at bsh.Interpreter.Line(Unknown Source) at bsh.Interpreter.eval(Unknown Source) at bsh.Interpreter.eval(Unknown Source) at com.funambol.foundation.synclet.BeanShellSynclet.evalOutputScript(BeanShellSynclet.java:342) at com.funambol.foundation.synclet.BeanShellSynclet.getOutputSynclet(BeanShellSynclet.java:303) at com.funambol.foundation.synclet.BeanShellSynclet.postProcessMessage(BeanShellSynclet.java:146) at com.funambol.framework.engine.pipeline.PipelineManager.postProcessMessage(PipelineManager.java:179) at com.funambol.server.engine.SyncAdapter.processWBXMLMessage(SyncAdapter.java:350) at com.funambol.transport.http.server.LocalSyncHolder.processWBXMLMessage(LocalSyncHolder.java:118) at com.funambol.transport.http.server.Sync4jServlet.doPost(Sync4jServlet.java:380) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.funambol.transport.http.server.LogContextFilter.doFilter(LogContextFilter.java:115) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Unknown Source) [2008-02-28 15:25:04,632] [funambol.transport.http] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Request processed. From groupdav@opengroupware.org Thu Feb 28 17:18:06 2008 From: groupdav@opengroupware.org (Peter Duda) Date: Thu, 28 Feb 2008 09:18:06 -0800 Subject: [GroupDAV] Syncing Nokia N73 with Funambol / Opengroupware In-Reply-To: <46e8a990802280727hb3a3ccxb08f999abe363507@mail.gmail.com> References: <46e8a990802280727hb3a3ccxb08f999abe363507@mail.gmail.com> Message-ID: <000901c87a2d$e2594f80$6601a8c0@PeterLaptop> >>GroupDAV Server: http://localhost:21000/ If I am remembering correctly port 21000 is used for the webui not for zidestore - zidestore uses 80 or 8080 (unless you changed something in your config) >> Modified groupdav-cal-v with: .. >> Applications->Calendar -> Remote database: groupdav-cal-s Looks like your names don't match - the remote databse name on your phone needs to match the config source (SyncML ID) you saved in Funambol That is what I see with my primitive knowledge :) Peter -----Original Message----- From: groupdav-admin@opengroupware.org [mailto:groupdav-admin@opengroupware.org] On Behalf Of Topper Doggle Sent: Thursday, February 28, 2008 7:28 AM To: groupdav@opengroupware.org Subject: [GroupDAV] Syncing Nokia N73 with Funambol / Opengroupware Hi, I've had an OGo server for a long time, and recently decided to try and get sync working to my N73 smartphone. I'm not having much luck so far, but there is so much to configure I wonder if it might be a config error rather than a bug. I'm trying to get calendar sync to work for starters. I'm using the Funambol / GroupDAV bundle from bionicmessage. Sync source settings ================ Modified groupdav-cal-v with: GroupDAV Server: http://localhost:21000/ (Funambol is on the same server as OGo / Zidestore.) Default calendar source: /zidestore/dav/%USER%/public/Calendar/ OGo all day event handling: ticked. N73 settings (all under Tools -> Sync -> OGo (new source I created) ========== Applications->Calendar -> Remote database: groupdav-cal-s Connection settings: Server version: 1.2 Host address: http://my.public.address/funambol/ds Port: 8080 The phone tries connecting then reports "system error". The (slightly munged) Funambol log follows. Hope someone can assist. [2008-02-28 15:25:00,752] [funambol.transport.http] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [] [] [] Handling incoming request [2008-02-28 15:25:00,752] [funambol.transport.http] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [] [] [] Request URL: http://my.public.server:8080/funambol/ds [2008-02-28 15:25:00,752] [funambol.transport.http] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [] [] [] Requested sessionId: null [2008-02-28 15:25:03,062] [funambol.engine.pipeline] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [] [] [] Input processing stopped by com.funambol.foundation.synclet.BeanShellSynclet@8d41f2[script=com/funambol/ server/engine/pipeline/phones-support/bsh/NokiaS60in.bsh,header=user-agent,p attern=Nokia SyncML HTTP Client] (reason: NokiaS60in Synclet finished) [2008-02-28 15:25:03,109] [funambol.handler] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] myuser/IMEI:mymungedimei logged in. [2008-02-28 15:25:03,316] [funambol.engine] [ERROR] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Error in processing the output message com.funambol.framework.core.Sync4jException: at com.funambol.foundation.synclet.BeanShellSynclet.getOutputSynclet(BeanShellS ynclet.java:307) at com.funambol.foundation.synclet.BeanShellSynclet.postProcessMessage(BeanShel lSynclet.java:146) at com.funambol.framework.engine.pipeline.PipelineManager.postProcessMessage(Pi pelineManager.java:179) at com.funambol.server.engine.SyncAdapter.processWBXMLMessage(SyncAdapter.java: 350) at com.funambol.transport.http.server.LocalSyncHolder.processWBXMLMessage(Local SyncHolder.java:118) at com.funambol.transport.http.server.Sync4jServlet.doPost(Sync4jServlet.java:3 80) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:173) at com.funambol.transport.http.server.LogContextFilter.doFilter(LogContextFilte r.java:115) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126 ) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105 ) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processC onnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.jav a:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWo rkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:684) at java.lang.Thread.run(Unknown Source) Caused by: Parse error at line 154, column 1. Encountered: << at bsh.Parser.generateParseException(Unknown Source) at bsh.Parser.jj_consume_token(Unknown Source) at bsh.Parser.Block(Unknown Source) at bsh.Parser.MethodDeclaration(Unknown Source) at bsh.Parser.BlockStatement(Unknown Source) at bsh.Parser.Line(Unknown Source) at bsh.Interpreter.Line(Unknown Source) at bsh.Interpreter.eval(Unknown Source) at bsh.Interpreter.eval(Unknown Source) at com.funambol.foundation.synclet.BeanShellSynclet.evalOutputScript(BeanShellS ynclet.java:342) at com.funambol.foundation.synclet.BeanShellSynclet.getOutputSynclet(BeanShellS ynclet.java:303) ... 24 more Parse error at line 154, column 1. Encountered: << at bsh.Parser.generateParseException(Unknown Source) at bsh.Parser.jj_consume_token(Unknown Source) at bsh.Parser.Block(Unknown Source) at bsh.Parser.MethodDeclaration(Unknown Source) at bsh.Parser.BlockStatement(Unknown Source) at bsh.Parser.Line(Unknown Source) at bsh.Interpreter.Line(Unknown Source) at bsh.Interpreter.eval(Unknown Source) at bsh.Interpreter.eval(Unknown Source) at com.funambol.foundation.synclet.BeanShellSynclet.evalOutputScript(BeanShellS ynclet.java:342) at com.funambol.foundation.synclet.BeanShellSynclet.getOutputSynclet(BeanShellS ynclet.java:303) at com.funambol.foundation.synclet.BeanShellSynclet.postProcessMessage(BeanShel lSynclet.java:146) at com.funambol.framework.engine.pipeline.PipelineManager.postProcessMessage(Pi pelineManager.java:179) at com.funambol.server.engine.SyncAdapter.processWBXMLMessage(SyncAdapter.java: 350) at com.funambol.transport.http.server.LocalSyncHolder.processWBXMLMessage(Local SyncHolder.java:118) at com.funambol.transport.http.server.Sync4jServlet.doPost(Sync4jServlet.java:3 80) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:173) at com.funambol.transport.http.server.LogContextFilter.doFilter(LogContextFilte r.java:115) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126 ) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105 ) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processC onnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.jav a:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWo rkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:684) at java.lang.Thread.run(Unknown Source) [2008-02-28 15:25:03,321] [funambol.transport.http] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Request processed. [2008-02-28 15:25:04,111] [funambol.transport.http] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Handling incoming request [2008-02-28 15:25:04,112] [funambol.transport.http] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Request URL: http://my.public.server:8080/funambol/ds [2008-02-28 15:25:04,112] [funambol.transport.http] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Requested sessionId: 88E1D57AAB7FE6F0FAF93237413B3699 [2008-02-28 15:25:04,542] [funambol.engine.pipeline] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Input processing stopped by com.funambol.foundation.synclet.BeanShellSynclet@8d41f2[script=com/funambol/ server/engine/pipeline/phones-support/bsh/NokiaS60in.bsh,header=user-agent,p attern=Nokia SyncML HTTP Client] (reason: NokiaS60in Synclet finished) [2008-02-28 15:25:04,548] [funambol.handler] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Handling mapping ... [2008-02-28 15:25:04,548] [funambol.handler] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Performing mapping ... [2008-02-28 15:25:04,626] [funambol.engine] [ERROR] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Error in processing the output message com.funambol.framework.core.Sync4jException: at com.funambol.foundation.synclet.BeanShellSynclet.getOutputSynclet(BeanShellS ynclet.java:307) at com.funambol.foundation.synclet.BeanShellSynclet.postProcessMessage(BeanShel lSynclet.java:146) at com.funambol.framework.engine.pipeline.PipelineManager.postProcessMessage(Pi pelineManager.java:179) at com.funambol.server.engine.SyncAdapter.processWBXMLMessage(SyncAdapter.java: 350) at com.funambol.transport.http.server.LocalSyncHolder.processWBXMLMessage(Local SyncHolder.java:118) at com.funambol.transport.http.server.Sync4jServlet.doPost(Sync4jServlet.java:3 80) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:173) at com.funambol.transport.http.server.LogContextFilter.doFilter(LogContextFilte r.java:115) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126 ) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105 ) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processC onnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.jav a:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWo rkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:684) at java.lang.Thread.run(Unknown Source) Caused by: Parse error at line 154, column 1. Encountered: << at bsh.Parser.generateParseException(Unknown Source) at bsh.Parser.jj_consume_token(Unknown Source) at bsh.Parser.Block(Unknown Source) at bsh.Parser.MethodDeclaration(Unknown Source) at bsh.Parser.BlockStatement(Unknown Source) at bsh.Parser.Line(Unknown Source) at bsh.Interpreter.Line(Unknown Source) at bsh.Interpreter.eval(Unknown Source) at bsh.Interpreter.eval(Unknown Source) at com.funambol.foundation.synclet.BeanShellSynclet.evalOutputScript(BeanShellS ynclet.java:342) at com.funambol.foundation.synclet.BeanShellSynclet.getOutputSynclet(BeanShellS ynclet.java:303) ... 24 more Parse error at line 154, column 1. Encountered: << at bsh.Parser.generateParseException(Unknown Source) at bsh.Parser.jj_consume_token(Unknown Source) at bsh.Parser.Block(Unknown Source) at bsh.Parser.MethodDeclaration(Unknown Source) at bsh.Parser.BlockStatement(Unknown Source) at bsh.Parser.Line(Unknown Source) at bsh.Interpreter.Line(Unknown Source) at bsh.Interpreter.eval(Unknown Source) at bsh.Interpreter.eval(Unknown Source) at com.funambol.foundation.synclet.BeanShellSynclet.evalOutputScript(BeanShellS ynclet.java:342) at com.funambol.foundation.synclet.BeanShellSynclet.getOutputSynclet(BeanShellS ynclet.java:303) at com.funambol.foundation.synclet.BeanShellSynclet.postProcessMessage(BeanShel lSynclet.java:146) at com.funambol.framework.engine.pipeline.PipelineManager.postProcessMessage(Pi pelineManager.java:179) at com.funambol.server.engine.SyncAdapter.processWBXMLMessage(SyncAdapter.java: 350) at com.funambol.transport.http.server.LocalSyncHolder.processWBXMLMessage(Local SyncHolder.java:118) at com.funambol.transport.http.server.Sync4jServlet.doPost(Sync4jServlet.java:3 80) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:173) at com.funambol.transport.http.server.LogContextFilter.doFilter(LogContextFilte r.java:115) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126 ) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105 ) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processC onnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.jav a:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWo rkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:684) at java.lang.Thread.run(Unknown Source) [2008-02-28 15:25:04,632] [funambol.transport.http] [INFO] [88E1D57AAB7FE6F0FAF93237413B3699] [IMEI:mymungedimei] [myuser] [] Request processed. -- GroupDAV groupdav@opengroupware.org http://mail.opengroupware.org/mailman/listinfo/groupdav From groupdav@opengroupware.org Thu Feb 28 17:26:02 2008 From: groupdav@opengroupware.org (Helge Hess) Date: Thu, 28 Feb 2008 18:26:02 +0100 Subject: [GroupDAV] Syncing Nokia N73 with Funambol / Opengroupware In-Reply-To: References: <46e8a990802280727hb3a3ccxb08f999abe363507@mail.gmail.com> Message-ID: On 28.02.2008, at 18:18, Peter Duda wrote: >>> GroupDAV Server: http://localhost:21000/ > If I am remembering correctly port 21000 is used for the webui not for > zidestore - zidestore uses 80 or 8080 (unless you changed something > in your > config) You should never access SOPE daemons on their direct port, they are not full HTTP servers. Setup mod_ngobjweb and tunnel through Apache as a frontend. If you have further questions please ask on the OGo users mailing list ... Helge -- Helge Hess http://www.helgehess.eu/ From groupdav@opengroupware.org Thu Feb 28 17:54:47 2008 From: groupdav@opengroupware.org (Topper Doggle) Date: Thu, 28 Feb 2008 17:54:47 +0000 Subject: [GroupDAV] Syncing Nokia N73 with Funambol / Opengroupware In-Reply-To: References: <46e8a990802280727hb3a3ccxb08f999abe363507@mail.gmail.com> Message-ID: <46e8a990802280954p671ae009vac9a275059686227@mail.gmail.com> On 28/02/2008, Peter Duda wrote: > >> Modified groupdav-cal-v with: > > >> Applications->Calendar -> Remote database: groupdav-cal-s > > Looks like your names don't match - the remote databse name on your phone > needs to match the config source (SyncML ID) you saved in Funambol > > That is what I see with my primitive knowledge :) Not so primitive, thank you, that was the issue! From groupdav@opengroupware.org Thu Feb 28 17:55:51 2008 From: groupdav@opengroupware.org (Topper Doggle) Date: Thu, 28 Feb 2008 17:55:51 +0000 Subject: [GroupDAV] Syncing Nokia N73 with Funambol / Opengroupware In-Reply-To: References: <46e8a990802280727hb3a3ccxb08f999abe363507@mail.gmail.com> Message-ID: <46e8a990802280955k5e3f5303q4c7bf52f6499da0@mail.gmail.com> On 28/02/2008, Helge Hess wrote: > On 28.02.2008, at 18:18, Peter Duda wrote: > >>> GroupDAV Server: http://localhost:21000/ > > If I am remembering correctly port 21000 is used for the webui not for > > zidestore - zidestore uses 80 or 8080 (unless you changed something > > in your > > config) > > > > You should never access SOPE daemons on their direct port, they are > not full HTTP servers. Setup mod_ngobjweb and tunnel through Apache as > a frontend. > If you have further questions please ask on the OGo users mailing > list ... > Oh. From the install doc PDF for the GroupDAV connector: "Please contact me or the GroupDAV mailing list with questions, not Funambol." From groupdav@opengroupware.org Thu Feb 28 18:11:23 2008 From: groupdav@opengroupware.org (Adam Tauno Williams) Date: Thu, 28 Feb 2008 13:11:23 -0500 Subject: [GroupDAV] Syncing Nokia N73 with Funambol / Opengroupware In-Reply-To: <46e8a990802280955k5e3f5303q4c7bf52f6499da0@mail.gmail.com> References: <46e8a990802280727hb3a3ccxb08f999abe363507@mail.gmail.com> <46e8a990802280955k5e3f5303q4c7bf52f6499da0@mail.gmail.com> Message-ID: <1204222283.5594.13.camel@WM_ADAM1.morrison.iserv.net> > > > If I am remembering correctly port 21000 is used for the webui not for > > > zidestore - zidestore uses 80 or 8080 (unless you changed something > > > in your > > > config) > > You should never access SOPE daemons on their direct port, they are > > not full HTTP servers. Setup mod_ngobjweb and tunnel through Apache as > > a frontend. > > If you have further questions please ask on the OGo users mailing > > list ... > Oh. From the install doc PDF for the GroupDAV connector: > "Please contact me or the GroupDAV mailing list with questions, not Funambol." It can be cloudy from the end-user perpestive, where to post questions. Questions *about* GroupDAV should go to the GroupDAV list, questions about using any GroupDAV software with a given server should first go to the server's support forum/list. At least that this how I understand it.