From groupdav@opengroupware.org Fri Jul 6 12:07:03 2007 From: groupdav@opengroupware.org (Mathew McBride) Date: Fri, 06 Jul 2007 21:07:03 +1000 Subject: [GroupDAV] GroupDAVOSX - GroupDAV connector for Mac OS X sync services Message-ID: Hello all, I'm proud to announce the release of GroupDAVOSX 0.1 - a Sync services connector for GroupDAV which brings true two-way sync between apps such as iCal, Entourage, iSync etc. and GroupDAV servers. Maybe those addicted to iPhones don't have to wait until 10.5 and CalDAV servers to sync up :-) A preview release is downloadable from http://bionicmessage.net/?q=node/17 . This release only supports basic calendar sync'ing - recurrences, attendees etc, and other data types such as tasks and contacts are not supported yet, but will be coming shortly. GroupDAVOSX uses the JGroupDAV client (used by the Funambol connector) so server compatibility should be quite good. At the moment only Citadel and OS X 10.4.10-x86* have been tested, other servers and PPC OSX will be tested shortly. If you want to try it out, please be aware that GroupDAVOSX is in alpha state - use dedicated test calendars and accounts. If things seem to break, the store log files (like the funambol connector) are located in ~/Library/Application Support/GroupDAVOSX/ and a log file for the most recent sync is in cat /tmp/groupdavosx.log . * Sync services only exists on 10.4 and later. - Mathew From groupdav@opengroupware.org Mon Jul 9 15:53:22 2007 From: groupdav@opengroupware.org (Raoul Cadei) Date: Mon, 9 Jul 2007 16:53:22 +0200 Subject: [GroupDAV] Ogo, Funambol and GroupDAV integration Message-ID: <002501c7c238$e5f6c3a0$0400a8c0@Borders> Good morning, I'm trying to setup a groupware server to sync with multiple platforms. I choose the OpenGroupware.org and Funambol synchronization server, but now I need a little help because something is working and something isn't. First of all the release of my system: CentOS 4.5 "vanilla" install; OpenGroupware 1.0.0, RPM packages built for CentOS; Funambol bundle 3 (DS server is version 5.0.10); GroupDAV connector version 1.1.1818; PostgreSQL version 7.4 (CentOS default packages). I followed the installation instructions found at: http://docs.opengroupware.org/Members/whitemice/applications/syncml/funambol -setup/view?searchterm=funambol And it tooks 10 minutes to set up the installation step-by-step. I also installed the Funambol Outlook plugin, and it is working, sending and receiving updates to my calendar and to my contacts. BUT.... I'm not able to get sync between Outlook and OGO. Indeed the synchronization is working only between Outlook and the Funambol ds server. No error in the Funambol log. Neither in the Tomcat one. I can see my contacts in the Funambol web demo. I have configured, using the Funambol Administration Tool, the GroupDav data source for calendar in the following way: SYncML Source URI: davOverview Source type: text/x-vcalendar GroupDAV URL: http://192.168.0.28:80/ Server source: /zidestore/dav/%USER%/Calendar/ Store location: /var/spool/groupdav/davOverview I did the same for the contacts. But I cannot get any synchronization between my outlook and my Ogo. Please can you help me to make some light on this little problem? Many thanks in advance. --- Raoul Cadei t.b. Mobile : +39.335.682.78.77 E-Mail : raoul.cadei@geekscube.com Web Site: http://www.motivegeeks.com/ Skype : callto://raoulcadei/ I solemnly swear that I am up to no good! From groupdav@opengroupware.org Mon Jul 9 16:22:16 2007 From: groupdav@opengroupware.org (Art Cancro) Date: Mon, 09 Jul 2007 11:22:16 -0400 Subject: [GroupDAV] Re: GroupDAVOSX Message-ID: <0002320425@uncensored.citadel.org> >I'm proud to announce the release of GroupDAVOSX 0.1 - a Sync services >connector for GroupDAV which brings true two-way sync between apps such as >iCal, Entourage, iSync etc. and GroupDAV servers. Maybe those addicted to >iPhones don't have to wait until 10.5 and CalDAV servers to sync up :-) As always, very nice work. Thank you once again for improving the value proposition of GroupDAV (and for once again proving that it's a better choice than CalDAV). From groupdav@opengroupware.org Mon Jul 9 18:20:49 2007 From: groupdav@opengroupware.org (Adam Tauno Williams) Date: Mon, 09 Jul 2007 13:20:49 -0400 Subject: [GroupDAV] Re: GroupDAVOSX In-Reply-To: <0002320425@uncensored.citadel.org> References: <0002320425@uncensored.citadel.org> Message-ID: <1184001649.4531.13.camel@aleph.whitemice.org> --=-IffPPtdOuvS0V9BFg/vZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > >I'm proud to announce the release of GroupDAVOSX 0.1 - a Sync services = =20 > >connector for GroupDAV which brings true two-way sync between apps such=20 > >as iCal, Entourage, iSync etc. and GroupDAV servers. Maybe those addicte= d=20 > >to iPhones don't have to wait until 10.5 and CalDAV servers to sync up := -) =20 > As always, very nice work.=20 Yes, this is great. > Thank you once again for improving the value=20 > proposition of GroupDAV (and for once again proving that it's a better=20 > choice than CalDAV). GroupDAV is not a replacement for CalDAV. --=-IffPPtdOuvS0V9BFg/vZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGkm5xLRePpNle04MRAutHAJ9/v28sfg0HtmElqND7z3gG0wfgRACdGWMo A5mOOEK4EYEgWQCRqtZTT68= =wtQk -----END PGP SIGNATURE----- --=-IffPPtdOuvS0V9BFg/vZ-- From groupdav@opengroupware.org Mon Jul 9 18:23:39 2007 From: groupdav@opengroupware.org (Adam Tauno Williams) Date: Mon, 09 Jul 2007 13:23:39 -0400 Subject: [GroupDAV] Ogo, Funambol and GroupDAV integration In-Reply-To: <002501c7c238$e5f6c3a0$0400a8c0@Borders> References: <002501c7c238$e5f6c3a0$0400a8c0@Borders> Message-ID: <1184001819.4531.17.camel@aleph.whitemice.org> --=-ZCObZ9ANor71lPCVm6od Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > I'm trying to setup a groupware server to sync with multiple > platforms. > I choose the OpenGroupware.org and Funambol synchronization server, but n= ow > I need a little help because something is working and something isn't. > First of all the release of my system: > CentOS 4.5 "vanilla" install; > OpenGroupware 1.0.0, RPM packages built for CentOS;=20 > Funambol bundle 3 (DS server is version 5.0.10);=20 > GroupDAV connector version 1.1.1818;=20 > PostgreSQL version 7.4 (CentOS default packages). > I followed the installation instructions found at: > http://docs.opengroupware.org/Members/whitemice/applications/syncml/funam= bol > -setup/view?searchterm=3Dfunambol > And it tooks 10 minutes to set up the installation step-by-step. > I also installed the Funambol Outlook plugin, and it is working, sending = and > receiving updates to my calendar and to my contacts. > BUT.... > I'm not able to get sync between Outlook and OGO. Indeed the synchronizat= ion > is working only between Outlook and the Funambol ds server. This statement doesn't make any sense. Are you sure you don't have the plugin configured to use the filesystem source on Funambol rather than your GroupDAV source? > No error in the Funambol log. What is the logging level set to? You should be able to see the GroupDAV exchange in the logs. > Neither in the Tomcat one. > I can see my contacts in the Funambol web demo. > I have configured, using the Funambol Administration Tool, the GroupDav d= ata > source for calendar in the following way: > SYncML Source URI: davOverview > Source type: text/x-vcalendar > GroupDAV URL: http://192.168.0.28:80/ > Server source: /zidestore/dav/%USER%/Calendar/ Store=20 What is " Store"? > location: /var/spool/groupdav/davOverview This directory exists and Fumanbol has permissions? Files are created there when you try to sync. --=-ZCObZ9ANor71lPCVm6od Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGkm8bLRePpNle04MRAsbvAJ4mDtAMgV8BLedAGXPxKLDE1U6yYwCdFSpM mudAdqbYpH7KSe8VZ1/pPrc= =ygbv -----END PGP SIGNATURE----- --=-ZCObZ9ANor71lPCVm6od-- From groupdav@opengroupware.org Mon Jul 9 18:29:06 2007 From: groupdav@opengroupware.org (Adam Tauno Williams) Date: Mon, 09 Jul 2007 13:29:06 -0400 Subject: [GroupDAV] Funambol connector git repository available In-Reply-To: References: Message-ID: <1184002146.4531.20.camel@aleph.whitemice.org> --=-yBF/WW0BuTSJFo8i0E4h Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > A git repository for the Funambol connector and JGroupDAV is now availabl= e: > http://bionicmessage.net/index.php?q=3Dnode/16 > It's been running internally for around two months but hosting issues > delayed public access. > Of particular note, as stated on the page, is that connector development = has > branched into two, one for future use with Funambol 6 and "stable" for > Funambol 5. Do you mean Funambol 3.0? (They jumped version numbers from 3.0 to 6.0) > The latest work on the "stable" branch, not yet compiled and release has = all > the dependencies moved into the s4j package for easier installation. > This also means those using jBoss 4x might want to phase it out - as the > libraries don't install properly on that platform. > The 'experimental' code for the new sync sources has been purged off the > stable branch too, but in terms of operation, there is nothing different. --=-yBF/WW0BuTSJFo8i0E4h Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGknBiLRePpNle04MRAm2JAJwJX/2o4srP8yKrVDe32xoSH8AoWQCePpqS bFqFbUjOqDtEMS9kx5y2ljM= =FHfv -----END PGP SIGNATURE----- --=-yBF/WW0BuTSJFo8i0E4h-- From groupdav@opengroupware.org Tue Jul 10 01:07:28 2007 From: groupdav@opengroupware.org (Mathew McBride) Date: Tue, 10 Jul 2007 10:07:28 +1000 Subject: [GroupDAV] Funambol connector git repository available In-Reply-To: <1184002146.4531.20.camel@aleph.whitemice.org> Message-ID: Yes. On 10/7/07 3:29 AM, "Adam Tauno Williams" wrote: >> A git repository for the Funambol connector and JGroupDAV is now available: >> http://bionicmessage.net/index.php?q=node/16 >> It's been running internally for around two months but hosting issues >> delayed public access. >> Of particular note, as stated on the page, is that connector development has >> branched into two, one for future use with Funambol 6 and "stable" for >> Funambol 5. > > Do you mean Funambol 3.0? (They jumped version numbers from 3.0 to 6.0) > >> The latest work on the "stable" branch, not yet compiled and release has all >> the dependencies moved into the s4j package for easier installation. >> This also means those using jBoss 4x might want to phase it out - as the >> libraries don't install properly on that platform. >> The 'experimental' code for the new sync sources has been purged off the >> stable branch too, but in terms of operation, there is nothing different. > From groupdav@opengroupware.org Tue Jul 10 02:05:18 2007 From: groupdav@opengroupware.org (Art Cancro) Date: Mon, 09 Jul 2007 21:05:18 -0400 Subject: [GroupDAV] GroupDAV vs. CalDAV Message-ID: <0002320616@uncensored.citadel.org> >GroupDAV is not a replacement for CalDAV. ...in your opinion. The last time this meta-discussion took place, it was discovered that there is no official position on GroupDAV's relationship to CalDAV, since the various implementors of GroupDAV have different goals for it. Some of us *do* believe that GroupDAV is *absolutely* a replacement for CalDAV, because CalDAV is an over-engineered mess of a protocol whose complexity encourages buggy, incompatible implementations. The fact that a GroupDAV implementation can be completed in a few days of coding, while a CalDAV implementation typically takes more than a year and still contains compatibility bugs, should suffice as proof that the GroupDAV-as-a-replacement-for-CalDAV approach is *quite* viable. You're entitled to take a different approach, of course. But please do not claim that there is a concensus or an official position. From groupdav@opengroupware.org Tue Jul 10 08:22:20 2007 From: groupdav@opengroupware.org (Julian Reschke) Date: Tue, 10 Jul 2007 09:22:20 +0200 Subject: [GroupDAV] GroupDAV vs. CalDAV In-Reply-To: <0002320616@uncensored.citadel.org> References: <0002320616@uncensored.citadel.org> Message-ID: <469333AC.6090604@gmx.de> Art Cancro wrote: > >GroupDAV is not a replacement for CalDAV. > > ...in your opinion. The last time this meta-discussion took place, it > was discovered that there is no official position on GroupDAV's > relationship to CalDAV, since the various implementors of GroupDAV have > different goals for it. > > Some of us *do* believe that GroupDAV is *absolutely* a replacement for > CalDAV, because CalDAV is an over-engineered mess of a protocol whose > complexity encourages buggy, incompatible implementations. > > The fact that a GroupDAV implementation can be completed in a few days of > coding, while a CalDAV implementation typically takes more than a year and > still contains compatibility bugs, should suffice as proof that the > GroupDAV-as-a-replacement-for-CalDAV approach is *quite* viable. > > You're entitled to take a different approach, of course. But please do > not claim that there is a concensus or an official position. Interesting discussion :-). Note from an observer: if you think that GroupDAV *is* a viable alternative to CalDAV, you probably should enhance groupdav.org, which currently points to a draft that was updated last almost three years ago (). Best regards, Julian From groupdav@opengroupware.org Tue Jul 10 11:02:42 2007 From: groupdav@opengroupware.org (Helge Hess) Date: Tue, 10 Jul 2007 12:02:42 +0200 Subject: [GroupDAV] GroupDAV vs. CalDAV In-Reply-To: <469333AC.6090604@gmx.de> References: <0002320616@uncensored.citadel.org> <469333AC.6090604@gmx.de> Message-ID: <7053CCF4-1AD1-4297-9C78-2337EA0DFD51@opengroupware.org> ... please not again ;-) Art: there *is* an official position of the authors (ups, thats me ;-) on the relationship to CalDAV. Its even in the FAQ. Opinions of implementers are their own, thanks ;-) Julian: since when does the _age_ of a draft matter? ;-) And what a 'viable alternative' is depends on the specific goals/needs. Adam: From an implementers POV GroupDAV can be a "replacement" for CalDAV - if you are fine with the facilities it provides. Obviously the GroupDAV draft is not a generic replacement for the CalDAV RFC (which of course was your initial point). People should take care about the context when they talk about 'GroupDAV'. Its easy to end up in flame wars otherwise. Is it an implementation, is it the draft, is it the overall project etc. Anyways, since the goal is being 'pragmatic' maybe its time to re- evaluate the position of GroupDAV in the current environment. I think the situation has changed a bit, with CalDAV released as an RFC, getting implemented by Mozilla and Apple, and CardDAV being in the works. From a (desktop) clients point of view CalDAV vs GroupDAV doesn't matter that much since the more advanced CalDAV features are all client initiated. From a servers point of view, especially for legacy ones, GroupDAV is *much* easier to implement. But implementing the necessary subset of CalDAV to please desktop clients is not _that_ hard either. Its only hard if you actually want to implement the standard :-) So I suppose what will happen is that plenty of servers will work with specific Sunbird or iCal.app versions, implementing just the CalDAV subset required to drive those. And they will label themselves 'CalDAV' servers, because they can talk to those specific CalDAV clients. Now that CalDAV subset should be pretty close to what is provided by GroupDAV. I wonder whether it would be the 'pragmatic way' to write down GroupDAV 2.0 as a 'best practice' of this CalDAV subset? I guess it will be GroupDAV-now plus 2 or 3 specific REPORTs. Other clients and servers could then use the subset as a basis to get started. I'm not sure. GroupDAV _is_ much simpler to implement in servers, even when we just consider reduced CalDAV. On the other side GroupDAV isn't that widely implemented in servers either. Though the latter is mostly because we did not really finish the goal yet of having great clients (the KDE plugin doesn't work sufficiently well, the Evolution plugin is OK but not 100% GroupDAV and we only have an AB plugin for Mozilla). The client situation isn't *that* much better for CalDAV, the interesting CalDAV clients are iCal.app and Sunbird (AFAIK no non- alpha Kontact or Evo connectors). I think we probably won't get Apple to make iCal.app support GroupDAV directly. Adding GroupDAV support to Sunbird should be an option (after all we already have the contact extension). Also interesting is that none of the big vendors seem to care about either ;-) Even Google does its own proprietary stuff. So the direction is not entirely clear. I suppose we should wait a bit longer and see what happens with CalDAV/CardDAV. Greets, Helge -- Helge Hess http://www.helgehess.eu/ From groupdav@opengroupware.org Tue Jul 10 11:21:02 2007 From: groupdav@opengroupware.org (Julian Reschke) Date: Tue, 10 Jul 2007 12:21:02 +0200 Subject: [GroupDAV] GroupDAV vs. CalDAV In-Reply-To: <7053CCF4-1AD1-4297-9C78-2337EA0DFD51@opengroupware.org> References: <0002320616@uncensored.citadel.org> <469333AC.6090604@gmx.de> <7053CCF4-1AD1-4297-9C78-2337EA0DFD51@opengroupware.org> Message-ID: <46935D8E.7010607@gmx.de> Helge Hess wrote: > ... > Julian: since when does the _age_ of a draft matter? ;-) And what a > 'viable alternative' is depends on the specific goals/needs. > ... Helge, the *age* doesn't matter in itself. But right now the reader gets the impression that it's not maintained. So, if it's stable, why is it still called "draft"? Speaking of which, were you considering to submit it to the IETF? > ... Best regards, Julian From groupdav@opengroupware.org Tue Jul 10 11:47:08 2007 From: groupdav@opengroupware.org (Helge Hess) Date: Tue, 10 Jul 2007 12:47:08 +0200 Subject: [GroupDAV] GroupDAV vs. CalDAV In-Reply-To: <46935D8E.7010607@gmx.de> References: <0002320616@uncensored.citadel.org> <469333AC.6090604@gmx.de> <7053CCF4-1AD1-4297-9C78-2337EA0DFD51@opengroupware.org> <46935D8E.7010607@gmx.de> Message-ID: <308FF95D-777E-4EC3-9D59-416952046BCE@opengroupware.org> On 10.07.2007, at 12:21, Julian Reschke wrote: > the *age* doesn't matter in itself. But right now the reader gets > the impression that it's not maintained. > > So, if it's stable, why is it still called "draft"? It is not stable, there are some loose ends and you are right that it isn't actively maintained :-) I've presented some thoughts on how we might want to continue in my mail. In fact I'm not even sure whether GroupDAV should ever leave the draft state. I guess I want it to be implementer driven, eg someone can convince the given (small) set of implementers of a certain feature / way and we just release a new draft. [obviously keeping compat in mind] BTW: I do think that even the 2003 GroupDAV draft has its use. After all there _are_ several implementations in active development. And thats the basic idea :-) > Speaking of which, were you considering to submit it to the IETF? No. Do you think that this would make sense? We already have CalDAV as the 'proper', 'well defined' RFC? The approach I envisioned compares more to XML-RPC than to SOAP :-) And the differences between GroupDAV and CalDAV should be quite similiar. Greets, Helge -- Helge Hess http://www.helgehess.eu/ From groupdav@opengroupware.org Tue Jul 10 13:58:51 2007 From: groupdav@opengroupware.org (Adam Tauno Williams) Date: Tue, 10 Jul 2007 08:58:51 -0400 Subject: [GroupDAV] GroupDAV vs. CalDAV In-Reply-To: <7053CCF4-1AD1-4297-9C78-2337EA0DFD51@opengroupware.org> References: <0002320616@uncensored.citadel.org> <469333AC.6090604@gmx.de> <7053CCF4-1AD1-4297-9C78-2337EA0DFD51@opengroupware.org> Message-ID: <1184072331.4492.40.camel@aleph.whitemice.org> --=-+68ZC0vnRI5xCb5utkEp Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > ... please not again ;-) Didn't mean to start 'a thing'. > Julian: since when does the _age_ of a draft matter? ;-) And what a =20 > 'viable alternative' is depends on the specific goals/needs. > Adam: From an implementers POV GroupDAV can be a "replacement" for =20 > CalDAV - if you are fine with the facilities it provides. Obviously =20 > the GroupDAV draft is not a generic replacement for the CalDAV RFC =20 > (which of course was your initial point). Yep, that is all I meant. Several things are possible with CalDAV that aren't with GroupDAV; thus I think calling it [generically] a replacement is at least confusing. > People should take care about the context when they talk about =20 > 'GroupDAV'. Its easy to end up in flame wars otherwise. Is it an =20 > implementation, is it the draft, is it the overall project etc. > Anyways, since the goal is being 'pragmatic' maybe its time to re-=20 > evaluate the position of GroupDAV in the current environment. I think =20 > the situation has changed a bit, with CalDAV released as an RFC, =20 > getting implemented by Mozilla and Apple, and CardDAV being in the =20 > works. > From a (desktop) clients point of view CalDAV vs GroupDAV doesn't =20 > matter that much since the more advanced CalDAV features are all =20 > client initiated. For me the principle problem with GroupDAV [aside from the shaky state of the current clients] are - Permissions: For CalDAV there is "A CalDAV server MUST support the WebDAV ACLs standard [7]" In an enterprise context [at least ours :)] operating without anyway to set/get permissions is a pretty serious drawback. The folder model of permissions can work, and works better with recent fixes to ZideStore (this is in relation to OGo) but is still rather limited / cumbersome. Just the ability to know that a given appointment cannot be modified would be sufficient for most situations. http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=3D1099 Otherwise the UI is 'dumb' and seems to permit modifications that then fail with an error [ or fail with no error! :) ]; this creates users who think the system is broken. Maybe other people's users are more tolerant than mine. Of course I haven't seen a CalDAV client that implements this, so.... whatever. :) Performance: With lots of data and no bulk get method GroupDAV over a WAN isn't stellar, especially if you have LOTS of data. Thousands of individual requests also hurt the server. The client having to basically pull all available data and do a local search is a pretty serious limitation; and the state of local clients is that they *ALL* fail when presented with thousands of contacts. But I accept that GroupDAV may simply not be suitable for this situation. But I've ended up creating my own solutions so allot of this is academic to me. However I would like to see 'generic' clients work better as some users very much like them. Funambol is my only real use of GroupDAV at this point. > From a servers point of view, especially for legacy ones, GroupDAV =20 > is *much* easier to implement. Agree, GroupDAV (at least for basic get/put) is really really easy. Doing the client side cache correctly/efficiently seems to be a major problem with all current clients. But this really isn't a failing of GroupDAV. > So I suppose what will happen is that plenty of servers will work =20 > with specific Sunbird or iCal.app versions, implementing just the =20 > CalDAV subset required to drive those. And they will label themselves =20 > 'CalDAV' servers, because they can talk to those specific CalDAV =20 > clients. Yep, I think that is pretty clearly what is going to happen. No surprise; look at the number of applications that "support" LDAP but don't chase referrals or dereferance aliases or that "support" Kerberos but go all monkey-poo when they see a post-dated ticket. Ugh. Funny how the Open Source crowd raves about open standards and then piddles all over them. Sorry.... it is hard not to rant. ;) > The client situation isn't *that* much better for CalDAV, the =20 > interesting CalDAV clients are iCal.app and Sunbird (AFAIK no non-=20 > alpha Kontact or Evo connectors). Yep, all pretty dodgy. > I think we probably won't get Apple to make iCal.app support GroupDAV =20 > directly. Adding GroupDAV support to Sunbird should be an option =20 > (after all we already have the contact extension). > Also interesting is that none of the big vendors seem to care about =20 > either ;-) Even Google does its own proprietary stuff. There is a legitimate argument that most of these standards force least-common-denominator behavior. From a solution providers perspective if using standard A means my client can't do/support/use features X, Y, or Z, then... And when 'the standards' try to compensate by being thorough, like CalDAV, then everyone complains about how complicated the standard is. Thus, people just roll-their-own. =20 > So the direction is not entirely clear. I suppose we should wait a =20 > bit longer and see what happens with CalDAV/CardDAV. --=-+68ZC0vnRI5xCb5utkEp Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGk4KLLRePpNle04MRAtR2AJ4r1689B9Y9DbLdjic9Vgep1ahJvQCffDAq ICxSvsk/mpg+5EcnflQeFTg= =wBmi -----END PGP SIGNATURE----- --=-+68ZC0vnRI5xCb5utkEp-- From groupdav@opengroupware.org Tue Jul 10 14:30:58 2007 From: groupdav@opengroupware.org (Helge Hess) Date: Tue, 10 Jul 2007 15:30:58 +0200 Subject: [GroupDAV] GroupDAV vs. CalDAV In-Reply-To: <1184072331.4492.40.camel@aleph.whitemice.org> References: <0002320616@uncensored.citadel.org> <469333AC.6090604@gmx.de> <7053CCF4-1AD1-4297-9C78-2337EA0DFD51@opengroupware.org> <1184072331.4492.40.camel@aleph.whitemice.org> Message-ID: On 10.07.2007, at 14:58, Adam Tauno Williams wrote: > Yep, that is all I meant. Several things are possible with CalDAV > that > aren't with GroupDAV; thus I think calling it [generically] a > replacement is at least confusing. Yes. > For me the principle problem with GroupDAV [aside from the shaky state > of the current clients] are - > > Permissions: For CalDAV there is "A CalDAV server MUST support the > WebDAV ACLs standard [7]" In an enterprise context [at least ours :)] > operating without anyway to set/get permissions is a pretty serious > drawback. Nothing prevents a GroupDAV server from supporting WebDAV ACLs? (or any other WebDAV or HTTP extension). The client can easily discover whether WebDAV ACLs are supported and then provide a UI (or not). [same for locking, BTW] This has not that much to do with GroupDAV. > The folder model of permissions can work, and works better > with recent fixes to ZideStore (this is in relation to OGo) but is > still rather limited / cumbersome. Specific to the OGo implementation of GroupDAV. This has nothing to do with the *GroupDAV* draft. It would be nice to enhance ZideStore to support WebDAV ACLs. > Just the ability to know that a given > appointment cannot be modified would be sufficient for most > situations. > http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1099 Yes, that would be very useful and simple enough for GroupDAV. > Of course I haven't seen a CalDAV client that implements this, so.... > whatever. :) Precisely ;-) > Performance: With lots of data and no bulk get method GroupDAV over a > WAN isn't stellar, especially if you have LOTS of data. Thousands of > individual requests also hurt the server. The client having to > basically pull all available data and do a local search is a pretty > serious limitation; and the state of local clients is that they *ALL* > fail when presented with thousands of contacts. But I accept that > GroupDAV may simply not be suitable for this situation. I really don't buy this argument. The many GETs are only necessary at the initial cache fill, which is usually performed in the LAN and can use a persistent HTTP connection. Afterwards its only the etag PROPFIND which is quite efficient and works for tens of thousands of entries with (assuming proper content compression). A multi-GET might be quite useful, but its quite a complication of the protocol (especially because its neither in HTTP nor in WebDAV) and is IMHO not strictly necessary in the real-world (because its a one-time operation). Well, an MGET would give a huge speed-up for database based servers like OGo. Maybe it _is_ worth adding, probably. The targetted clients needs to pull all the items for offline capability anyways. The searches must be implemented in the client anyways due to this. In fact thats a basic assumption of GroupDAV. Supporting serverside queries is a useless complication because the client has to do it anyways for offline operation. > However I would like to see 'generic' clients work better as > some users very much like them. The problem is that 'generic' quickly ends when you work with permissions ... >> From a servers point of view, especially for legacy ones, GroupDAV >> is *much* easier to implement. > Agree, GroupDAV (at least for basic get/put) is really really easy. > Doing the client side cache correctly/efficiently seems to be a major > problem with all current clients. But this really isn't a failing of > GroupDAV. Exactly. A CalDAV client (with offline capability) would need to exactly the same. And writing the cache is *really* no rocket science but almost trivial (its just keying the content on URL+etag?!). Not sure why (whether) the clients would have issues with that. Greets, Helge -- Helge Hess http://www.helgehess.eu/ From groupdav@opengroupware.org Tue Jul 10 16:07:14 2007 From: groupdav@opengroupware.org (Wolfgang Sourdeau) Date: Tue, 10 Jul 2007 11:07:14 -0400 Subject: [GroupDAV] online SOGo demo Message-ID: <49e8ca7ad0fab64a976b29e6f8d31bc4@mozzarella> Hi everybody, We are happy to announce that our demo website for SOGo is now available. You can access it by pointing your web browser to http://sogo-demo.inverse.ca/. Usernames and passwords are provided on the main page, as well as basic instructions on how to access the data with Thunderbird and Lightning in GroupDAV/CalDAV. Please note that the Safari / IE 7 / Opera support isn't yet completed so it's currently best for you to try it using Firefox. Wolfgang From groupdav@opengroupware.org Wed Jul 11 05:18:27 2007 From: groupdav@opengroupware.org (Art Cancro) Date: Wed, 11 Jul 2007 00:18:27 -0400 Subject: [GroupDAV] GroupDAV vs. CalDAV Message-ID: <0002321011@uncensored.citadel.org> >Art: there *is* an official position of the authors (ups, thats >me ;-) on the relationship to CalDAV. Its even in the FAQ. Opinions >of implementers are their own, thanks ;-) Like it or not, GroupDAV is bigger than just you. As a leader, it is your responsibility to arbitrate to concensus rather than simply making broad declarations on behalf of the rest of us -- even if that concensus is as simple as "no official position." If a top-down approach was your intention then it should have been called "OGo sync protocol" rather than GroupDAV. Forgive me if I'm a *bit* defensive about this topic, but it's a bit of a sore spot. -- Art From groupdav@opengroupware.org Thu Jul 19 21:07:42 2007 From: groupdav@opengroupware.org (Wolfgang Sourdeau) Date: Thu, 19 Jul 2007 16:07:42 -0400 Subject: [GroupDAV] prepackaged SOGo/SOPE Message-ID: <0a940b93770d9d2dc86cc55e0b2ee98b@mozzarella> Hi everyone, This is to announce that prepackaged RPMs are now availble for SOGo and SOPE (GNUstep build) at http://www.inverse.ca/SOGo/ The current distributions are currently limited to CentOS/RHEL 5 but more is to come soon. Thanks! Wolfgang From groupdav@opengroupware.org Tue Jul 24 14:59:24 2007 From: groupdav@opengroupware.org (=?ISO-8859-15?Q?Samuli_Sepp=E4nen?=) Date: Tue, 24 Jul 2007 16:59:24 +0300 Subject: [GroupDAV] Problem with VCALENDARs with DESCRIPTION field containing line feeds Message-ID: <46A605BC.8080803@tietoteema.fi> Hi! I've finally managed to sort out most issues with Zidestore 1.5 <-> GroupDAV connector <-> Funambol <-> Nokia S60 synchronization. There is one problem, however... Whenever I create an event in OGo and write a multiline comment for it, it doesn't get synced at all. All VCALENDARs that contain a multiline DESCRIPTION fail consistently, so linefeeds are obviously the source of the problem. These multiline DESCRIPTION events do appear in the GroupDAV connector logs, but they never gets to the Nokia. I suppose GroupDAV connector is rejecting it. The OGo event comment get mapped to DESCRIPTION in the VCALENDAR's VEVENT subsection. When I view the multiline DESCRIPTION field with either "less" or "vi", this is what I get: --- snip --- DESCRIPTION:John Doe\, mobile. 555 123456^M\n^M\nSee: http://www.johndoe.com/ (Pages are not in use yet) --- snip --- This is from GroupDAV connector logs, of course. This does not look right. There should not be any ^M 's (either a CR or LF, I can't never remember). From RFC2445 (http://www.faqs.org/rfcs/rfc2445.html): description = "DESCRIPTION" descparam ":" text CRLF --- snip --- Example: The following is an example of the property with formatted line breaks in the property value: DESCRIPTION:Meeting to provide technical review for "Phoenix" design.\n Happy Face Conference Room. Phoenix design team MUST attend this meeting.\n RSVP to team leader. The following is an example of the property with folding of long lines: DESCRIPTION:Last draft of the new novel is to be completed for the editor's proof today. --- snip --- This clearly states that the DESCRIPTION field should contain only \n as the linefeed, or CRLF linefeed. Or possibly both, if I understand correctly. No DOS/Mac linefeed (just CR or LF, not CRLF). Is this just Zidestore serving invalid VCALENDAR files, or is GroupDAV connector doing something it shouldn't? Samuli From groupdav@opengroupware.org Tue Jul 24 15:09:23 2007 From: groupdav@opengroupware.org (Helge Hess) Date: Tue, 24 Jul 2007 16:09:23 +0200 Subject: [GroupDAV] Problem with VCALENDARs with DESCRIPTION field containing line feeds In-Reply-To: <46A605BC.8080803@tietoteema.fi> References: <46A605BC.8080803@tietoteema.fi> Message-ID: <28A3FDF5-8F47-4031-B9A6-DBF660A29691@opengroupware.org> On 24.07.2007, at 15:59, Samuli Sepp=E4nen wrote: > Is this just Zidestore serving invalid VCALENDAR files Apparently the CRs are not properly escaped (or removed) in the =20 comment content. Maybe thats confusing the vcard4j, yes. Helge --=20 Helge Hess http://www.helgehess.eu/ From groupdav@opengroupware.org Wed Jul 25 10:59:05 2007 From: groupdav@opengroupware.org (=?ISO-8859-1?Q?Samuli_Sepp=E4nen?=) Date: Wed, 25 Jul 2007 12:59:05 +0300 Subject: [GroupDAV] Problem with VCALENDARs with DESCRIPTION field containing line feeds In-Reply-To: <28A3FDF5-8F47-4031-B9A6-DBF660A29691@opengroupware.org> References: <46A605BC.8080803@tietoteema.fi> <28A3FDF5-8F47-4031-B9A6-DBF660A29691@opengroupware.org> Message-ID: <46A71EE9.1080101@tietoteema.fi> > On 24.07.2007, at 15:59, Samuli Seppänen wrote: >> Is this just Zidestore serving invalid VCALENDAR files > > Apparently the CRs are not properly escaped (or removed) in the comment > content. Maybe thats confusing the vcard4j, yes. > > Helge Ok, I'll file a bug report against Zidestore. Samuli From groupdav@opengroupware.org Mon Jul 30 09:26:59 2007 From: groupdav@opengroupware.org (Stephan Skrodzki) Date: Mon, 30 Jul 2007 10:26:59 +0200 Subject: [GroupDAV] Evo Groupdav & Instant OGO Message-ID: <1185784019.6075.16.camel@localhost> Hi there, I installed a Test Version of Instant OGO and it seems, that the Evo Groupdav connector is not working with the Zidestore server of Instant OGO. Before I start posting logs and deeper analysis I have just a simple question: did anybody manage to get InstantOGO and Evo/GroupDAV working together (at least with calender and contact sync)? Regs STephan From groupdav@opengroupware.org Mon Jul 30 13:28:07 2007 From: groupdav@opengroupware.org (Adam Tauno Williams) Date: Mon, 30 Jul 2007 08:28:07 -0400 Subject: [GroupDAV] Evo Groupdav & Instant OGO In-Reply-To: <1185784019.6075.16.camel@localhost> References: <1185784019.6075.16.camel@localhost> Message-ID: <1185798487.5050.7.camel@aleph.whitemice.org> --=-b7JMJE4komem7ZCBs5P5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > I installed a Test Version of Instant OGO and it seems, that the Evo > Groupdav connector is not working with the Zidestore server of Instant > OGO.=20 > Before I start posting logs and deeper analysis I have just a simple > question:=20 > did anybody manage to get InstantOGO and Evo/GroupDAV working together > (at least with calender and contact sync)? The evolution connector seems to be unmaintained and, at least IMHO, is unusable. The calendar should work somewhat with a reasonably current version of Zidestore but the addressbook either just does nothing or crashes the EDS. --=-b7JMJE4komem7ZCBs5P5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGrdlXLRePpNle04MRArQgAJ9H87KpLsA1bkha/UlRuqH4QpNW5QCeMsW7 QDxZD9Kt4OTGy5cu5Gr6aWo= =IEVM -----END PGP SIGNATURE----- --=-b7JMJE4komem7ZCBs5P5-- From groupdav@opengroupware.org Mon Jul 30 13:31:23 2007 From: groupdav@opengroupware.org (Adam Tauno Williams) Date: Mon, 30 Jul 2007 08:31:23 -0400 Subject: [GroupDAV] eM Client (?) Message-ID: <1185798683.5050.9.camel@aleph.whitemice.org> --=-k5aZielh2J+294/tQQ5+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Bumped into a new GroupDAV client, or at least new to me - http://www.emclient.com/faq/ --=-k5aZielh2J+294/tQQ5+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGrdobLRePpNle04MRAuAlAJ9Z/4b58lj5ppuHx6hoReBRyp/NKgCaAzqB ohw+Z9wZWUPt9P6t2N+ERHo= =EnoO -----END PGP SIGNATURE----- --=-k5aZielh2J+294/tQQ5+-- From groupdav@opengroupware.org Mon Jul 30 17:49:43 2007 From: groupdav@opengroupware.org (Robert de Geus) Date: Mon, 30 Jul 2007 18:49:43 +0200 Subject: [GroupDAV] Evo Groupdav & Instant OGO Message-ID: <1185814183.10298.18.camel@salsa-10-1-0-177.nim> --=-M1m2xqfK5cULc/8qknDA Content-Type: text/plain Content-Transfer-Encoding: 7bit >> I installed a Test Version of Instant OGO and it seems, that the Evo >> Groupdav connector is not working with the Zidestore server of Instant >> OGO. >> Before I start posting logs and deeper analysis I have just a simple >> question: >> did anybody manage to get InstantOGO and Evo/GroupDAV working together >> (at least with calender and contact sync)? >The evolution connector seems to be unmaintained and, at least IMHO, is >unusable. The calendar should work somewhat with a reasonably current >version of Zidestore but the addressbook either just does nothing or >crashes the EDS. We have build the connector to work with Opengroupware version svn1923. evolution 2.10.1, running under Ubuntu feisty. The connector is functional for Calendar items. Contacts and Tasks are not fully supported. We use the Connector in production environments but mainly as a central Calendar. Unfortunately Shreyas, the main developer and maintainer, is very busy at the moment. What the project needs is that more people test te connector with the various versions (OpenGroupware, SOGO, InstantOGO, Skyrix) and deliver good bug reports. The project needs to be pushed forward, and therefore a combined effort from all sides is essential. If a couple of companies would like to advance the connector, we could ask Shreyas again if he can find some more time. gr. Robert --=-M1m2xqfK5cULc/8qknDA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit >> I installed a Test Version of Instant OGO and it seems, that the Evo 
>> Groupdav connector is not working with the Zidestore server of Instant
>> OGO. 
>> Before I start posting logs and deeper analysis I have just a simple
>> question: 
>> did anybody manage to get InstantOGO and Evo/GroupDAV working together
>> (at least with calender and contact sync)?

>The evolution connector seems to be unmaintained and, at least IMHO, is
>unusable.  The calendar should work somewhat with a reasonably current
>version of Zidestore but the addressbook either just does nothing or
>crashes the EDS.

We have build the connector to work with Opengroupware version svn1923. evolution 2.10.1, running
under Ubuntu feisty. 

The connector is functional for Calendar items. Contacts and Tasks are not fully supported. 
We use the Connector in production environments but mainly as a central Calendar.

Unfortunately Shreyas, the main developer and maintainer, is very busy at the moment. 
What the project needs is that more people test te connector with the various versions 
(OpenGroupware, SOGO, InstantOGO, Skyrix) and deliver good bug reports. 

The project needs to be pushed forward, and therefore a combined effort from all sides is essential. 
If a couple of companies would like to advance the connector, 
we could ask Shreyas again if he can find some more time. 

gr.
Robert
--=-M1m2xqfK5cULc/8qknDA-- From groupdav@opengroupware.org Tue Jul 31 10:57:08 2007 From: groupdav@opengroupware.org (Stephan Skrodzki) Date: Tue, 31 Jul 2007 09:57:08 +0000 Subject: [GroupDAV] Evo Groupdav & Instant OGO In-Reply-To: <1185814183.10298.18.camel@salsa-10-1-0-177.nim> References: <1185814183.10298.18.camel@salsa-10-1-0-177.nim> Message-ID: <1185875828.6075.92.camel@localhost> Hi Robert, thx for that clarification! Am Montag, den 30.07.2007, 18:49 +0200 schrieb Robert de Geus: > We have build the connector to work with Opengroupware version svn1923. evolution 2.10.1, running > under Ubuntu feisty. > > The connector is functional for Calendar items. Contacts and Tasks are not fully supported. > We use the Connector in production environments but mainly as a central Calendar. Could you please describe what is functional for the Contacts and what not? We did not get anything to run for the contacts here... > Unfortunately Shreyas, the main developer and maintainer, is very busy at the moment. > What the project needs is that more people test te connector with the various versions > (OpenGroupware, SOGO, InstantOGO, Skyrix) and deliver good bug reports. > The project needs to be pushed forward, and therefore a combined effort from all sides is essential. > If a couple of companies would like to advance the connector, > we could ask Shreyas again if he can find some more time. I agree with you, but - to have a little bit a "customers" standpoint - for the OpenGroupware Versions which are part of a selling offer, I would think that it should be a work mainly support by the commercial vendors of those versions... Somehow, the whole situation seems quite disappointing for me/my company as pure users: We are mainly using Evolution as our mail/calendar clients, we have a few outlook users, some MacOS users... then, what would be the best solution for shared calendars and shared contacts? OGO with commercial Zidestore? Skalix? Groupwise? Citadel? BTW: What is the status about the Evo GroupDAV Plugin and Citadel? Is this more promising? Best regards Stephan P.S. Please do not blame me for having a "customer attitude" on OSS projects. We could spend some (very little) money in that. I am just astonished, that there was no real evolution on the whole Evo/OGO (or GroupWare at all) issue in the last years (up to what I see...) From groupdav@opengroupware.org Tue Jul 31 11:09:58 2007 From: groupdav@opengroupware.org (Helge Hess) Date: Tue, 31 Jul 2007 12:09:58 +0200 Subject: [GroupDAV] Evo Groupdav & Instant OGO In-Reply-To: <1185875828.6075.92.camel@localhost> References: <1185814183.10298.18.camel@salsa-10-1-0-177.nim> <1185875828.6075.92.camel@localhost> Message-ID: On 31.07.2007, at 11:57, Stephan Skrodzki wrote: > I agree with you, but - to have a little bit a "customers" standpoint Could you please move away such discussions to appropriate lists, eg discuss@opengroupware.org? This is the mailing list for developers working on the GroupDAV protocol. Thanks a lot, Helge -- Helge Hess http://www.helgehess.eu/ From groupdav@opengroupware.org Tue Jul 31 11:26:22 2007 From: groupdav@opengroupware.org (Stephan Skrodzki) Date: Tue, 31 Jul 2007 10:26:22 +0000 Subject: [GroupDAV] Evo Groupdav & Instant OGO In-Reply-To: References: <1185814183.10298.18.camel@salsa-10-1-0-177.nim> <1185875828.6075.92.camel@localhost> Message-ID: <1185877582.6075.102.camel@localhost> Am Dienstag, den 31.07.2007, 12:09 +0200 schrieb Helge Hess: > Could you please move away such discussions to appropriate lists, eg > discuss@opengroupware.org? > > This is the mailing list for developers working on the GroupDAV > protocol. then you should change the statement on the GroupDAV.org site: "Feel free to join the discussion and specification of GroupDAV by subscribing to our mailing list." It is not my intention to discuss the status of OpenGroupware but still I am interested in the status of Evo and the GroupDav Plugin. Could you recommend another mailing list for that? Regs Stephan From groupdav@opengroupware.org Tue Jul 31 13:16:27 2007 From: groupdav@opengroupware.org (Adam Tauno Williams) Date: Tue, 31 Jul 2007 08:16:27 -0400 Subject: [GroupDAV] Evo Groupdav & Instant OGO In-Reply-To: <1185877582.6075.102.camel@localhost> References: <1185814183.10298.18.camel@salsa-10-1-0-177.nim> <1185875828.6075.92.camel@localhost> <1185877582.6075.102.camel@localhost> Message-ID: <1185884187.4386.5.camel@aleph.whitemice.org> --=-Zv6wYB2TY1x14ooUEvtc Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > > Could you please move away such discussions to appropriate lists, eg =20 > > discuss@opengroupware.org? > > This is the mailing list for developers working on the GroupDAV =20 > > protocol. > then you should change the statement on the GroupDAV.org site: > "Feel free to join the discussion and specification of GroupDAV by > subscribing to our mailing list." > It is not my intention to discuss the status of OpenGroupware but still But it is: "for the OpenGroupware Versions which are part of a selling offer" That is a question specifically about OpenGroupware. > I am interested in the status of Evo and the GroupDav Plugin. Could you > recommend another mailing list for that? You cannot draw a bright-clear-line between what a/the plugin supports and what the server supports. Your question is best posed to the opengroupware list AND the citadel list [as separate messages! DO NOT CROSS POST.] if you want specific information on how-well/if each supports GroupDAV in some fashion. It is on each projects lists that you are most likely to find people with specific experience with the interaction of the server via whatever protocol. --=-Zv6wYB2TY1x14ooUEvtc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGrygbLRePpNle04MRAjxmAJ4ijCx9stkwKf3NmVGHdFAJBMPRjACfaEaA OOIMu5dJl1bjkxWsDNEIk/k= =aFpd -----END PGP SIGNATURE----- --=-Zv6wYB2TY1x14ooUEvtc--