From developer@opengroupware.org Thu Aug 2 07:01:45 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Thu, 02 Aug 2007 08:01:45 +0200 Subject: [OGo-Developer] anybody on ccc camp? Message-ID: <20070802060145.B77E845C88@l00-bugdead-prods.de> Hi there, will there be anybody on the camp next week? https://www.ccc.de/camp/2007 It's cheap and usually means a lot of fun and other interesting stuff. If so, it would be nice to meet and talk about OGo in real life. kind regards Sebastian From developer@opengroupware.org Thu Aug 2 07:11:27 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Thu, 02 Aug 2007 08:11:27 +0200 Subject: [OGo-Developer] anybody on ccc camp? Message-ID: <20070802061127.D611E45CED@l00-bugdead-prods.de> developer@opengroupware.org wrote: > Hi there, > > will there be anybody on the camp next week? > https://www.ccc.de/camp/2007 the correct link: https://www.ccc.de/camp/2007 > It's cheap and usually means a lot of fun and other interesting stuff. > > > If so, it would be nice to meet and talk about OGo in real life. > > kind regards > Sebastian > > -- > OpenGroupware.org Developer > developer@opengroupware.org > http://mail.opengroupware.org/mailman/listinfo/developer > From developer@opengroupware.org Wed Aug 15 17:02:50 2007 From: developer@opengroupware.org (Sebastian Reitenbach) Date: Wed, 15 Aug 2007 18:02:50 +0200 Subject: [OGo-Developer] someone is spamming bugzilla Message-ID: <20070815160251.09B8B4975A@l00-bugdead-prods.de> hi, http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=116 I just recognized the attachements to that bug above, can the attachements get removed from bugzilla? kind regards Sebastian From developer@opengroupware.org Sun Aug 19 01:02:18 2007 From: developer@opengroupware.org (Michael Schmidt) Date: Sun, 19 Aug 2007 02:02:18 +0200 Subject: [OGo-Developer] adding RS Instant Messenger to opengroupware Message-ID: <5cc93d950708181702u383fbb0dv884d5f0e3dfe35be@mail.gmail.com> Hello want to suggest to add serverless and secure Instant Chat Messenger to Opengroupware: http://sourceforge.net/forum/forum.php?forum_id=618174 Uses c++ and QT gui. With file transfer in a secure way for collaborating in teams on documents synchronized in a secure way. What has to be done, to get it listed and in the suite? As well an integration into the email client would be of interest, to bring online and offline communication into one frame. (this dual core under one gui could be as well complementary outsourced to OOo). Thanks for a short feedback. Regards Mike From developer@opengroupware.org Sun Aug 19 02:35:33 2007 From: developer@opengroupware.org (Adam Tauno Williams) Date: Sat, 18 Aug 2007 21:35:33 -0400 Subject: [OGo-Developer] adding RS Instant Messenger to opengroupware In-Reply-To: <5cc93d950708181702u383fbb0dv884d5f0e3dfe35be@mail.gmail.com> References: <5cc93d950708181702u383fbb0dv884d5f0e3dfe35be@mail.gmail.com> Message-ID: <1187487333.4901.9.camel@aleph.wmmi.net> > want to suggest to add serverless and secure Instant Chat Messenger to > Opengroupware: > http://sourceforge.net/forum/forum.php?forum_id=618174 I don't understand this link, it points to Retroshare which is self-described as: "Retroshare is a cross-platform private p2p sharing program. It lets you share securely your friends, using a web-of-trust to authenticate peers and OpenSSL to encrypt all communication. RetroShare provides filesharing, chat, messages and channels." OpenGroupware is a groupware server, so I don't see the overlap with a peer-to-peer system. As you describe it "serverless" and OGo is a *server*. :) But maybe I'm just missing something obvious. > Uses c++ and QT gui. > With file transfer in a secure way for collaborating in teams on > documents synchronized in a secure way. > What has to be done, to get it listed and in the suite? > As well an integration into the email client would be of interest, to > bring online and offline communication into one frame. > (this dual core under one gui could be as well complementary outsourced to OOo). If you want to support the RS protocol and the RS protocol is HTTP based you can probably implement a ZideStore bundle. If you want to support it in the WebUI when you need to create a bundle there. Check out http://svn.opengroupware.org/viewcvs/trunk/Misc/ for example WebUI bundles and http://svn.opengroupware.org/viewcvs/trunk/ZideStore/Protocols/ for examples of ZideStore bundles. From developer@opengroupware.org Sun Aug 19 03:08:08 2007 From: developer@opengroupware.org (Michael Schmidt) Date: Sun, 19 Aug 2007 04:08:08 +0200 Subject: [OGo-Developer] adding RS Instant Messenger to opengroupware In-Reply-To: <1187487333.4901.9.camel@aleph.wmmi.net> References: <5cc93d950708181702u383fbb0dv884d5f0e3dfe35be@mail.gmail.com> <1187487333.4901.9.camel@aleph.wmmi.net> Message-ID: <5cc93d950708181908x3f158448l899a3683ec0397a9@mail.gmail.com> Hi Adam, thanks for the feedback, yes I saw it to late, your gui is webbased, and you have no email client, groupware is a server for that... sorry.. thanks!! Kind regard Mike On 8/19/07, Adam Tauno Williams wrote: > > want to suggest to add serverless and secure Instant Chat Messenger to > > Opengroupware: > > http://sourceforge.net/forum/forum.php?forum_id=618174 > > I don't understand this link, it points to Retroshare which is > self-described as: "Retroshare is a cross-platform private p2p sharing > program. It lets you share securely your friends, using a web-of-trust > to authenticate peers and OpenSSL to encrypt all communication. > RetroShare provides filesharing, chat, messages and channels." > > OpenGroupware is a groupware server, so I don't see the overlap with a > peer-to-peer system. As you describe it "serverless" and OGo is a > *server*. :) But maybe I'm just missing something obvious. > > > Uses c++ and QT gui. > > With file transfer in a secure way for collaborating in teams on > > documents synchronized in a secure way. > > What has to be done, to get it listed and in the suite? > > As well an integration into the email client would be of interest, to > > bring online and offline communication into one frame. > > (this dual core under one gui could be as well complementary outsourced to OOo). > > If you want to support the RS protocol and the RS protocol is HTTP based > you can probably implement a ZideStore bundle. If you want to support > it in the WebUI when you need to create a bundle there. Check out > http://svn.opengroupware.org/viewcvs/trunk/Misc/ for example WebUI > bundles and > http://svn.opengroupware.org/viewcvs/trunk/ZideStore/Protocols/ for > examples of ZideStore bundles. > > -- > OpenGroupware.org Developer > developer@opengroupware.org > http://mail.opengroupware.org/mailman/listinfo/developer > From developer@opengroupware.org Sun Aug 19 19:01:15 2007 From: developer@opengroupware.org (Adam Tauno Williams) Date: Sun, 19 Aug 2007 14:01:15 -0400 Subject: [OGo-Developer] zOGI uploaded [Was: Re: Consonance Snapshot] In-Reply-To: <6AE0AEC7-553C-4D5B-B1BB-2372ED7DC76B@opengroupware.org> References: <1186434006.4519.2.camel@aleph.whitemice.org> <6AE0AEC7-553C-4D5B-B1BB-2372ED7DC76B@opengroupware.org> Message-ID: <1187546475.4256.3.camel@aleph.wmmi.net> On Mon, 2007-08-06 at 23:51 +0200, Helge Hess wrote: > On 06.08.2007, at 23:00, Adam Tauno Williams wrote: > > * zOGI r550 or newer installed in ZideStore > Would it be time to commit zOGI to the main branch of ZideStore? I've sent zOGI upstream in r1995. I think I did everything correctly; it compiles, packages, and install correctly (at least for me). From developer@opengroupware.org Sun Aug 19 20:12:53 2007 From: developer@opengroupware.org (Helge Hess) Date: Sun, 19 Aug 2007 21:12:53 +0200 Subject: [OGo-Developer] zOGI uploaded [Was: Re: Consonance Snapshot] In-Reply-To: <1187546475.4256.3.camel@aleph.wmmi.net> References: <1186434006.4519.2.camel@aleph.whitemice.org> <6AE0AEC7-553C-4D5B-B1BB-2372ED7DC76B@opengroupware.org> <1187546475.4256.3.camel@aleph.wmmi.net> Message-ID: <7AB6DBCC-4B40-4B31-A928-01B6FFB473A0@opengroupware.org> On 19.08.2007, at 20:01, Adam Tauno Williams wrote: > On Mon, 2007-08-06 at 23:51 +0200, Helge Hess wrote: >> On 06.08.2007, at 23:00, Adam Tauno Williams wrote: >>> * zOGI r550 or newer installed in ZideStore >> Would it be time to commit zOGI to the main branch of ZideStore? > I've sent zOGI upstream in r1995. I think I did everything correctly; > it compiles, packages, and install correctly (at least for me). Great! Thanks a lot, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Tue Aug 21 14:54:04 2007 From: developer@opengroupware.org (Adam Tauno Williams) Date: Tue, 21 Aug 2007 09:54:04 -0400 Subject: [OGo-Developer] zOGI uploaded [Was: Re: Consonance Snapshot] In-Reply-To: <7AB6DBCC-4B40-4B31-A928-01B6FFB473A0@opengroupware.org> References: <1186434006.4519.2.camel@aleph.whitemice.org> <6AE0AEC7-553C-4D5B-B1BB-2372ED7DC76B@opengroupware.org> <1187546475.4256.3.camel@aleph.wmmi.net> <7AB6DBCC-4B40-4B31-A928-01B6FFB473A0@opengroupware.org> Message-ID: <1187704444.5045.4.camel@aleph.wmmi.net> --=-i8M56QVxz3EPg3umJqPv Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2007-08-19 at 21:12 +0200, Helge Hess wrote: > On 19.08.2007, at 20:01, Adam Tauno Williams wrote: > > On Mon, 2007-08-06 at 23:51 +0200, Helge Hess wrote: > >> On 06.08.2007, at 23:00, Adam Tauno Williams wrote: > >>> * zOGI r550 or newer installed in ZideStore > >> Would it be time to commit zOGI to the main branch of ZideStore? > > I've sent zOGI upstream in r1995. I think I did everything correctly; > > it compiles, packages, and install correctly (at least for me). > Great! Maybe I did miss something; entries in the ChangeLog don't appear on the ChangeBlogger. It is OK with me if they aren't supposed to, it just made me wonder. --=-i8M56QVxz3EPg3umJqPv 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) iD8DBQBGyu58LRePpNle04MRAlUpAJ4wAgzEDmZBe9Pr4uUpRQuU74mFMwCeK6nt 2GM18tr42cYqJLgmjGuSUkQ= =lIjg -----END PGP SIGNATURE----- --=-i8M56QVxz3EPg3umJqPv-- From developer@opengroupware.org Wed Aug 22 23:09:29 2007 From: developer@opengroupware.org (Wolfgang Sourdeau) Date: Wed, 22 Aug 2007 18:09:29 -0400 Subject: [OGo-Developer] multipart/form-data and text encoding Message-ID: Hi all, We are using UTF-8 everywhere in SOGo. However Firefox and IE do not seem to specify the charset of the information they send when POSTing a form. I have filled a bugreport with regard to that issue here: http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1868 I don't know whether this has been handled. I think there was mention of modifying the parsers instead during one of my discussions with Helge Hess. Regarding the specific case of multipart/form-data input fields, the problem arises again. I have thus filled another bug report and a patch as attachment: http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1903 Since I have doubts with regards to the correct handling of that case, I would appreciate if somebody who is more familiar with that code could review it, and maybe apply it. Thanks Wolfgang From developer@opengroupware.org Thu Aug 23 00:43:00 2007 From: developer@opengroupware.org (Helge Hess) Date: Thu, 23 Aug 2007 01:43:00 +0200 Subject: [OGo-Developer] Re: additional field for synchronizatin In-Reply-To: References: Message-ID: <86038C4A-49DE-4EDF-8C9B-81F6EBC8C310@opengroupware.org> ... moving to the list ... On 22.08.2007, at 20:09, Wolfgang Sourdeau wrote: > We are working on a plugin for Funambol for enabling users to > synchronize their data with SOGo. > The remaining issue is that events and contacts deleted from the > server by the web ui or in dav are not deleted in Funambol since > there is no way to know whether en entry has been deleted or not. > THe solution I have in mind for this was to add a field "c_deleted" > to the quicktables. Once this flag would be active, the elements > would no longer appear in SOGo (web or dav) but the funambol > connector would still see them as deleted. > > From there, a cronjob should run periodically to effectively delete > those objects from the database. IMHO (if I remember SyncML right) this is wrong. SyncML transactions are just that, transactions. Whether an object is deleted is keyed to the state of the SyncML transaction, not to the object itself (which might even get resurrected!). Ie SyncML needs to know which objects got deleted since the last transaction, not *all* deleted objects (this would slow it down significantly, much more than the initial GroupDAV fetch overhead!). I think the proper thing to do for Funambol is to create a separate, SyncML transaction table which maps a specific path+etag state to the relevant transaction-id (not sure whether Funambol exposes the TX-ID, some specific timestamp might do). But besides that, I don't have objections to a deleted flag. Really deleting the data is rarely useful :-) (assuming that vCards/iCals usually don't consume GBs of data ...) Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Thu Aug 23 18:04:57 2007 From: developer@opengroupware.org (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Thu, 23 Aug 2007 19:04:57 +0200 Subject: [OGo-Developer] multipart/form-data and text encoding In-Reply-To: References: Message-ID: <2E93BCB1-E593-44C7-B17A-3F3A641F810C@sente.ch> Hi, I think I had the same kind of problem with WebObjects, and solved it =20= by setting the 'accept-charset' attribute on the form element: this =20 tells the client to use the passed charset, not a 'random' (server's =20 POV) one. St=E9phane On Aug 23, 2007, at 12:09 AM, Wolfgang Sourdeau wrote: > Hi all, > > > We are using UTF-8 everywhere in SOGo. However Firefox and IE do =20 > not seem to specify the charset of the information they send when =20 > POSTing a form. > > I have filled a bugreport with regard to that issue here: > http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=3D1868 > > I don't know whether this has been handled. I think there was =20 > mention of modifying the parsers instead during one of my =20 > discussions with Helge Hess. > > Regarding the specific case of multipart/form-data input fields, =20 > the problem arises again. > I have thus filled another bug report and a patch as attachment: > http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=3D1903 > > Since I have doubts with regards to the correct handling of that =20 > case, I would appreciate if somebody who is more familiar with that =20= > code could review it, and maybe apply it. > > > Thanks > > > Wolfgang > --=20 > OpenGroupware.org Developer > developer@opengroupware.org > http://mail.opengroupware.org/mailman/listinfo/developer From developer@opengroupware.org Thu Aug 23 19:27:32 2007 From: developer@opengroupware.org (Wolfgang Sourdeau) Date: Thu, 23 Aug 2007 14:27:32 -0400 Subject: [OGo-Developer] multipart/form-data and text encoding In-Reply-To: <2E93BCB1-E593-44C7-B17A-3F3A641F810C@sente.ch> Message-ID: <61fdd8185482a3d4637b0f8e3b882b01@mozzarella> On 2007-08-23 12:04:57 -0500 St=E9phane Corth=E9sy w= rote: > Hi, >=20 > I think I had the same kind of problem with WebObjects, and solved it = by=20 > setting the 'accept-charset' attribute on the form element: this tell= s the=20 > client to use the passed charset, not a 'random' (server's POV) one. >=20 > St=E9phane I have already tried that and it didn't change anything. I think this fi= eld is only meant for the client to understand which kind of encoding it= can use. >From http://www.w3.org/TR/html401/interact/forms.html#adef-accept-charse= t: "accept-charset =3D charset list [CI] This attribute specifies the list of character encodings for input d= ata that is accepted by the server processing this form. The value is a = space- and/or comma-delimited list of charset values. The client must in= terpret this list as an exclusive-or list, i.e., the server is able to a= ccept any single character encoding per entity received. The default value for this attribute is the reserved string "UNKNOWN= ". User agents may interpret this value as the character encoding that w= as used to transmit the document containing this FORM element." I don't know it it is even useful... Wolfgang From developer@opengroupware.org Thu Aug 23 20:01:38 2007 From: developer@opengroupware.org (Helge Hess) Date: Thu, 23 Aug 2007 21:01:38 +0200 Subject: [OGo-Developer] multipart/form-data and text encoding In-Reply-To: References: Message-ID: <8DC1D781-CA75-4DEE-9975-BB0D2CA370CF@opengroupware.org> On 23.08.2007, at 00:09, Wolfgang Sourdeau wrote: > I think there was mention of modifying the parsers instead I have not found the time to look at the changes yet, but changing default encodings for decoding from ASCII to UTF-8 should almost always make sense (since every ASCII char is a valid UTF-8 char). Anyways, the more important thing is that we should not work on NGHttpRequest and the NGMime based HTTP parser! Quite a while ago I started that "SimpleHTTPParser" which can be enabled using the "WOHttpTransactionUseSimpleParser" default. (and in fact its much more reliable and efficient for WebDAV usage!, so its recommended for ZideStore/xmlrpcd) The NGMime stuff is *quite* complex (and I'm relunctant to change a lot there, because it works quite well for b0rked messages). This is necessary for mail, but completely unnecessary for HTTP which is rather clean and well implemented in 'da real world. There is only one issue which is why the SimpleParser is not enabled by default: it doesn't implement multipart/formdata=>WORequest decoding (which is not that hard, but some work). So IMHO the proper thing would be to finish the SimpleParser instead of tweaking NGMime. If you would want to do this, it would be a welcome and useful addition to SOPE. Helge PS: I'll have a look at the patch later this week. -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Thu Aug 23 20:08:21 2007 From: developer@opengroupware.org (Wolfgang Sourdeau) Date: Thu, 23 Aug 2007 15:08:21 -0400 Subject: [OGo-Developer] Re: additional field for synchronizatin In-Reply-To: <86038C4A-49DE-4EDF-8C9B-81F6EBC8C310@opengroupware.org> Message-ID: <189049f51cd34ac20cf8f455948de0cc@mozzarella> On 2007-08-22 18:43:00 -0500 Helge Hess wrote: > IMHO (if I remember SyncML right) this is wrong. SyncML transactions > are > just that, transactions. Whether an object is deleted is keyed to > the state > of the SyncML transaction, not to the object itself (which might > even get > resurrected!). Ie SyncML needs to know which objects got deleted > since the > last transaction, not *all* deleted objects (this would slow it down > significantly, much more than the initial GroupDAV fetch overhead!). That is what we do. Ludovic's plugin receives a query about which elements were deleted from this to that date. By setting "c_deleted" to 1 and updating the "c_lastmodified" field, I can answer taht question appropriately without returning every deleted events. The idea of a log table would be specific to Funambol, but the idea of adding the "c_deleted" field can be considered as a facility of SOGo/SOPE which could probably be useful to other synchronisation systems too. Regarding your etag thing, I don't think it would be useful here since Ludovic's plugin directly talk to the SOGo database, so it doesn't rely on groupdav to communicate with SOGo. W. From developer@opengroupware.org Thu Aug 23 20:11:31 2007 From: developer@opengroupware.org (Wolfgang Sourdeau) Date: Thu, 23 Aug 2007 15:11:31 -0400 Subject: [OGo-Developer] multipart/form-data and text encoding In-Reply-To: <8DC1D781-CA75-4DEE-9975-BB0D2CA370CF@opengroupware.org> Message-ID: <59030e208019fe8f14384898f85b311f@mozzarella> On 2007-08-23 14:01:38 -0500 Helge Hess wrote: > On 23.08.2007, at 00:09, Wolfgang Sourdeau wrote: >> I think there was mention of modifying the parsers instead > > I have not found the time to look at the changes yet, but changing > default > encodings for decoding from ASCII to UTF-8 should almost always make > sense > (since every ASCII char is a valid UTF-8 char). My idea is actually that the parser or the parser delegate should return the charset for NGMime objects which have none specified. Hence the change to return nil instead of returning a default, in NGMimeBodyPart. > Anyways, the more important thing is that we should not work on > NGHttpRequest and the NGMime based HTTP parser! Quite a while ago I > started > that "SimpleHTTPParser" which can be enabled using the > "WOHttpTransactionUseSimpleParser" default. (and in fact its much > more > reliable and efficient for WebDAV usage!, so its recommended for > ZideStore/xmlrpcd) > > The NGMime stuff is *quite* complex (and I'm relunctant to change a > lot > there, because it works quite well for b0rked messages). This is > necessary > for mail, but completely unnecessary for HTTP which is rather clean > and well > implemented in 'da real world. I could do this and then rely on the WOMessageUseUTF8 to parse the results. We might as well change WOMessageUseUTF8 to WOMessageCharset instead, for the sake people using yet another different charset. > There is only one issue which is why the SimpleParser is not enabled > by > default: it doesn't implement multipart/formdata=>WORequest decoding > (which > is not that hard, but some work). I already did such a parser in perl a few years ago, I think I could write one very quickly. Wolfgang From developer@opengroupware.org Thu Aug 23 20:12:34 2007 From: developer@opengroupware.org (Helge Hess) Date: Thu, 23 Aug 2007 21:12:34 +0200 Subject: [OGo-Developer] multipart/form-data and text encoding In-Reply-To: <61fdd8185482a3d4637b0f8e3b882b01@mozzarella> References: <61fdd8185482a3d4637b0f8e3b882b01@mozzarella> Message-ID: <333A9C8A-F9D0-468F-B5FE-7BF02351BDC4@opengroupware.org> On 23.08.2007, at 20:27, Wolfgang Sourdeau wrote: > I have already tried that and it didn't change anything. I think > this field is only meant for the client to understand which kind of > encoding it can use. Yes. Didn't Google even include the charset as a query parameter in various URLs? The real bug is that the browser do not specify the charset in the content-type (and since there are different opinions on the default, they should *always* specify the charset). Anyways, I think the usual way it works is that the form values are in the same encoding like the originating page. If UTF-8 is used everywhere, it should be quite OK. *Though* the default charset for HTTP is Latin-1, not UTF-8. So this is non exactly correct. Putting the behaviour into a delegate method sounds like a sane thing to do, though using UTF-8 as the default (instead of Latin1) _might_ be viable too (would need to be checked against OGo which does rely on Latin1). Thanks, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Thu Aug 23 20:16:42 2007 From: developer@opengroupware.org (Wolfgang Sourdeau) Date: Thu, 23 Aug 2007 15:16:42 -0400 Subject: [OGo-Developer] multipart/form-data and text encoding Message-ID: > *Though* the default charset for HTTP is Latin-1, not UTF-8. So this > is non exactly correct. > Putting the behaviour into a delegate method sounds like a sane thing > to do, though using UTF-8 as the default (instead of Latin1) _might_ > be viable too (would need to be checked against OGo which does rely > on Latin1). My patch returns a default based on "WOMessgeUseUTF8": --- NGObjWeb/WOHttpAdaptor/WOHttpTransaction.m (r=C3=A9vision 1528) +++ NGObjWeb/WOHttpAdaptor/WOHttpTransaction.m (copie de travail) @@ -31,6 +31,7 @@ #include #include #include +#include #include "common.h" #include @@ -60,6 +61,7 @@ static BOOL useSimpleParser =3D YES; static int doCore =3D -1; static NSString *adLogPath =3D nil; +static NGMimeType *defaultMimeType =3D nil; static NGLogger *debugLogger =3D nil; static NGLogger *perfLogger =3D nil; static NGLogger *transActionLogger =3D nil; @@ -83,7 +85,11 @@ ud =3D [NSUserDefaults standardUserDefaults]; useSimpleParser =3D [ud boolForKey:@"WOHttpTransactionUseSimpleParser"]; doCore =3D [[ud objectForKey:@"WOCoreOnHTTPAdaptorException"] boolValue]?1:0; - + if ([ud boolForKey: @"WOMessageUseUTF8"]) + defaultMimeType =3D [NGMimeType mimeType: @"text/plain; charset=3Dutf-8"]; + else + defaultMimeType =3D [NGMimeType mimeType: @"text/plain; charset=3Diso-8859-1"]; + [defaultMimeType retain]; adLogPath =3D [[ud stringForKey:@"WOAdaptorLogPath"] copy]; if (adLogPath =3D=3D nil) adLogPath =3D @""; } ... so this problem is handled already ;) W. From developer@opengroupware.org Thu Aug 23 20:17:32 2007 From: developer@opengroupware.org (Helge Hess) Date: Thu, 23 Aug 2007 21:17:32 +0200 Subject: [OGo-Developer] multipart/form-data and text encoding In-Reply-To: <59030e208019fe8f14384898f85b311f@mozzarella> References: <59030e208019fe8f14384898f85b311f@mozzarella> Message-ID: On 23.08.2007, at 21:11, Wolfgang Sourdeau wrote: > I could do this and then rely on the WOMessageUseUTF8 to parse the > results. We might as well change > WOMessageUseUTF8 to WOMessageCharset instead, for the sake people > using yet another different charset. Sounds reasonable, though I'm personally not sure why we would support anything but legacy (Latin1) and UTF-8. >> There is only one issue which is why the SimpleParser is not >> enabled by default: it doesn't implement multipart/ >> formdata=>WORequest decoding (which is not that hard, but some >> work). > I already did such a parser in perl a few years ago, I think I > could write one very quickly. Its not really hard. But it would be really nice (but no initial requirement) if it would work efficiently with large (file) uploads by streaming them to a mapped file. There is a special NSData object for that, which is in fact used in the simple parser for WebDAV PUT, which is why it is recommended for ZideStore. Thanks, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Thu Aug 23 20:19:07 2007 From: developer@opengroupware.org (Wolfgang Sourdeau) Date: Thu, 23 Aug 2007 15:19:07 -0400 Subject: [OGo-Developer] multipart/form-data and text encoding Message-ID: Actually... What I worry about, since I lack experience yet with this API is what delegate has to be modified for the default to be set to "us-ascii" when its an email that's being parsed... In this patch I handle HTTP, but the email parsing is probably broken now with regards to the standard behaviour of defaulting charset to us-ascii... Wolfgang From developer@opengroupware.org Thu Aug 23 20:26:10 2007 From: developer@opengroupware.org (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Thu, 23 Aug 2007 21:26:10 +0200 Subject: [OGo-Developer] multipart/form-data and text encoding In-Reply-To: <61fdd8185482a3d4637b0f8e3b882b01@mozzarella> References: <61fdd8185482a3d4637b0f8e3b882b01@mozzarella> Message-ID: On Aug 23, 2007, at 8:27 PM, Wolfgang Sourdeau wrote: > On 2007-08-23 12:04:57 -0500 St=E9phane Corth=E9sy = =20 > wrote: > >> Hi, >> >> I think I had the same kind of problem with WebObjects, and solved =20= >> it by >> setting the 'accept-charset' attribute on the form element: this =20 >> tells the >> client to use the passed charset, not a 'random' (server's POV) one. >> >> St=E9phane > > I have already tried that and it didn't change anything. I think =20 > this field is only meant for the client to understand which kind of =20= > encoding it can use. > >> =46rom http://www.w3.org/TR/html401/interact/forms.html#adef-accept-=20= >> charset: > > "accept-charset =3D charset list [CI] > This attribute specifies the list of character encodings for =20 > input data that is accepted by the server processing this form. The =20= > value is a space- and/or comma-delimited list of charset values. =20 > The client must interpret this list as an exclusive-or list, i.e., =20 > the server is able to accept any single character encoding per =20 > entity received. > > The default value for this attribute is the reserved string =20 > "UNKNOWN". User agents may interpret this value as the character =20 > encoding that was used to transmit the document containing this =20 > FORM element." > > I don't know it it is even useful... As I understand it, if my form has accept-charset=3D"utf-8", then the =20= client has to return form data encoded in UTF-8 - not ISOLatin1, nor =20 any other encoding. Thus, on the server-side, you can safely decode =20 form data from UTF-8. Isn't it what's happening? St=E9phane > Wolfgang > > > -- > OpenGroupware.org Developer > developer@opengroupware.org > http://mail.opengroupware.org/mailman/listinfo/developer From developer@opengroupware.org Thu Aug 23 20:27:49 2007 From: developer@opengroupware.org (Helge Hess) Date: Thu, 23 Aug 2007 21:27:49 +0200 Subject: [OGo-Developer] Re: additional field for synchronizatin In-Reply-To: <189049f51cd34ac20cf8f455948de0cc@mozzarella> References: <189049f51cd34ac20cf8f455948de0cc@mozzarella> Message-ID: <7D404B76-49D3-4F16-9D20-5C274FDB776B@opengroupware.org> On 23.08.2007, at 21:08, Wolfgang Sourdeau wrote: > That is what we do. Ludovic's plugin receives a query about which > elements were deleted from this to that date. By setting > "c_deleted" to 1 and updating the "c_lastmodified" field, I can > answer taht question appropriately without returning every deleted > events. > > The idea of a log table would be specific to Funambol, but the idea > of adding the "c_deleted" field can be considered as a facility of > SOGo/SOPE which could probably be useful to other synchronisation > systems too. Might be. In fact OGo has "db_status" which is 'inserted', 'archived' or 'updated' (and quite often objects are "only" archived, not really deleted). Maybe use the same field instead of the plain c_deleted flag? I do not really like that the change states are stored in the table instead of a proper transaction table, but its probably the pragmatic thing to do. (querying c_lastmodified (a date) is highly unreliable given that you can have hundreds of updates in a second - which is extremely common especially during synchronizations - which is why there are SyncML anchors ...) > Regarding your etag thing, I don't think it would be useful here > since Ludovic's plugin directly talk to the SOGo database, so it > doesn't rely on groupdav to communicate with SOGo. ? The etag is stored in the database, its the object change marker (called object_version in OGo, don't remember about SOGo, but should be named similiar). Its not just used for GroupDAV (in fact thats not even GroupDAV, its plain HTML). Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Thu Aug 23 20:30:59 2007 From: developer@opengroupware.org (Helge Hess) Date: Thu, 23 Aug 2007 21:30:59 +0200 Subject: [OGo-Developer] multipart/form-data and text encoding In-Reply-To: References: <61fdd8185482a3d4637b0f8e3b882b01@mozzarella> Message-ID: On 23.08.2007, at 21:26, St=E9phane Corth=E9sy wrote: > As I understand it, if my form has accept-charset=3D"utf-8", then the =20= > client has to return form data encoded in UTF-8 - not ISOLatin1, =20 > nor any other encoding. Thus, on the server-side, you can safely =20 > decode form data from UTF-8. Isn't it what's happening? Yes, but how does SOPE know that the previous transaction was in =20 UTF-8 if the client doesn't transfer that information in the content-=20 type? Those are two separate HTTP transactions. As mentioned we could add a special WOFormCharset form value (like =20 Google does), or we could let the WOApplication decide if it knows =20 that it always generates UTF-8 (which I think is what Wolfgang's =20 patch does). Thanks, Helge --=20 Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Thu Aug 23 20:32:06 2007 From: developer@opengroupware.org (Helge Hess) Date: Thu, 23 Aug 2007 21:32:06 +0200 Subject: [OGo-Developer] multipart/form-data and text encoding In-Reply-To: References: Message-ID: <10A50810-8A22-4CEC-8748-1706BA39AAD1@opengroupware.org> On 23.08.2007, at 21:19, Wolfgang Sourdeau wrote: > What I worry about, since I lack experience yet with this API is > what delegate has to be modified for the default to be set to "us- > ascii" when its an email that's being parsed... Yes, thats why I recommended looking at the SimpleHTTPParser. Its much cleaner to finish that than to deal with NGMime. > In this patch I handle HTTP, but the email parsing is probably > broken now with regards to the standard behaviour of defaulting > charset to us-ascii... I'll review it, but I *guess* that UTF-8 should not hurt as mentioned before. Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Thu Aug 23 20:41:38 2007 From: developer@opengroupware.org (Wolfgang Sourdeau) Date: Thu, 23 Aug 2007 15:41:38 -0400 Subject: [OGo-Developer] Re: additional field for synchronizatin Message-ID: > I do not really like that the change states are stored in the table > instead of a proper transaction table, but its probably the pragmatic > thing to do. > (querying c_lastmodified (a date) is highly unreliable given that you > can have hundreds of updates in a second - which is extremely common > especially during synchronizations - which is why there are SyncML > anchors ...) Yes, you can have hundreds of updates in a second, but you'd have to be a cyborg to be able to do it on the same single event that belongs to you... the c_lastmodified and the c_deleted fields are per-event. Not per update. W. From developer@opengroupware.org Thu Aug 23 20:59:03 2007 From: developer@opengroupware.org (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Thu, 23 Aug 2007 21:59:03 +0200 Subject: [OGo-Developer] multipart/form-data and text encoding In-Reply-To: References: <61fdd8185482a3d4637b0f8e3b882b01@mozzarella> Message-ID: On Aug 23, 2007, at 9:30 PM, Helge Hess wrote: > On 23.08.2007, at 21:26, St=E9phane Corth=E9sy wrote: >> As I understand it, if my form has accept-charset=3D"utf-8", then =20 >> the client has to return form data encoded in UTF-8 - not =20 >> ISOLatin1, nor any other encoding. Thus, on the server-side, you =20 >> can safely decode form data from UTF-8. Isn't it what's happening? > > Yes, but how does SOPE know that the previous transaction was in =20 > UTF-8 if the client doesn't transfer that information in the =20 > content-type? Those are two separate HTTP transactions. Server sets the accept-charset attribute, so, when it receives the =20 form's submission, it should also now which accept-charset had been =20 set before. The easiest case, for developer, is to always set accept-=20 charset to the same value, and to invoke -[WORequest =20 setDefaultFormValueEncoding:] (with formValueEncodingDetectionEnabled =20= set to NO). That's what I did, IIRC. St=E9phane > As mentioned we could add a special WOFormCharset form value (like =20 > Google does), or we could let the WOApplication decide if it knows =20 > that it always generates UTF-8 (which I think is what Wolfgang's =20 > patch does). > > Thanks, > Helge > --=20 > Helge Hess > http://www.helgehess.eu/ > > > -- > OpenGroupware.org Developer > developer@opengroupware.org > http://mail.opengroupware.org/mailman/listinfo/developer From developer@opengroupware.org Thu Aug 23 22:20:29 2007 From: developer@opengroupware.org (Helge Hess) Date: Thu, 23 Aug 2007 23:20:29 +0200 Subject: [OGo-Developer] Re: additional field for synchronizatin In-Reply-To: References: Message-ID: <1EAD9E77-0E5D-4C68-B640-EB541128EAFE@opengroupware.org> On 23.08.2007, at 21:41, Wolfgang Sourdeau wrote: > Yes, you can have hundreds of updates in a second, but you'd have > to be a cyborg to be able to do it on the same single event that > belongs to you... Exactly, I was talking about a (automatic!) sync process, this can push hundreds of changes in a second (the likeliness of a conflict increases dramatically). Of course this matters less for private folders, but for shared ones it does! (IMHO the whole point for groupware ;-) Especially if the folders are supposed to scale the issue becomes more and more important. A single user can push a 100 changes to a shared folders which others may not see due to the 1s granularity of the timestamp. Anyways, I have nothing against ignoring the issue for now. Having a sync at all is more important in the first place ;-) Thanks, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Thu Aug 23 22:25:19 2007 From: developer@opengroupware.org (Helge Hess) Date: Thu, 23 Aug 2007 23:25:19 +0200 Subject: [OGo-Developer] multipart/form-data and text encoding In-Reply-To: References: <61fdd8185482a3d4637b0f8e3b882b01@mozzarella> Message-ID: On 23.08.2007, at 21:59, St=E9phane Corth=E9sy wrote: > Server sets the accept-charset attribute, so, when it receives the =20 > form's submission, it should also now which accept-charset had been =20= > set before. Well, its the application (XYZ) which sets the accept-charset, and =20 the framework (SOPE) which needs to decode it :-) So the app must =20 tell the framework ..., which brings us to: > The easiest case, for developer, is to always set accept-charset to =20= > the same value, and to invoke -[WORequest =20 > setDefaultFormValueEncoding:] (with =20 > formValueEncodingDetectionEnabled set to NO). That's what I did, IIRC. Hm: ---snip--- - (void)setDefaultFormValueEncoding:(NSStringEncoding)_enc { if (_enc !=3D NSUTF8StringEncoding || _enc !=3D = NSASCIIStringEncoding) [self notImplemented:_cmd]; } ---snap--- Looks we miss this for WO compat :-) Thanks a lot, Helge PS: of course the *real* issue is still the clients which do not =20 properly set the charset in the content-type :-( --=20 Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Thu Aug 23 22:27:31 2007 From: developer@opengroupware.org (Helge Hess) Date: Thu, 23 Aug 2007 23:27:31 +0200 Subject: [OGo-Developer] multipart/form-data and text encoding In-Reply-To: References: <61fdd8185482a3d4637b0f8e3b882b01@mozzarella> Message-ID: On 23.08.2007, at 23:25, Helge Hess wrote: > Hm: > ---snip--- > - (void)setDefaultFormValueEncoding:(NSStringEncoding)_enc { > if (_enc != NSUTF8StringEncoding || _enc != NSASCIIStringEncoding) > [self notImplemented:_cmd]; > } > ---snap--- > Looks we miss this for WO compat :-) Uhm, in case this wasn't obvious. If someone starts implementing form- value decoding in the simple parser, he should check - defaultFormValueEncoding to determine the default if the client gives none. (hint hint ;-) Thanks, Helge -- Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Fri Aug 24 20:55:10 2007 From: developer@opengroupware.org (Wolfgang Sourdeau) Date: Fri, 24 Aug 2007 15:55:10 -0400 Subject: [OGo-Developer] Re: additional field for synchronizatin In-Reply-To: <1EAD9E77-0E5D-4C68-B640-EB541128EAFE@opengroupware.org> Message-ID: <31b4d1e10ce2c63d3cf0036615dba42e@mozzarella> On 2007-08-23 16:20:29 -0500 Helge Hess wrote: > On 23.08.2007, at 21:41, Wolfgang Sourdeau wrote: >> Yes, you can have hundreds of updates in a second, but you'd have >> to be a >> cyborg to be able to do it on the same single event that belongs to >> you... > > Exactly, I was talking about a (automatic!) sync process, this can > push > hundreds of changes in a second (the likeliness of a conflict > increases > dramatically). Of course this matters less for private folders, but > for > shared ones it does! (IMHO the whole point for groupware ;-) > Especially if > the folders are supposed to scale the issue becomes more and more > important. > A single user can push a 100 changes to a shared folders which > others may > not see due to the 1s granularity of the timestamp. The chances that 2 users modify the same event (for exmaple, one change the start hour and the other deletes it) are really close to 0.0000001%. So I would not worry about that at all. Actually I wonder if you understand that we are talking of one field for each single event or task... W. From developer@opengroupware.org Fri Aug 24 22:51:12 2007 From: developer@opengroupware.org (Helge Hess) Date: Fri, 24 Aug 2007 23:51:12 +0200 Subject: [OGo-Developer] Re: additional field for synchronizatin In-Reply-To: <31b4d1e10ce2c63d3cf0036615dba42e@mozzarella> References: <31b4d1e10ce2c63d3cf0036615dba42e@mozzarella> Message-ID: On 24.08.2007, at 21:55, Wolfgang Sourdeau wrote: > The chances that 2 users modify the same event (for exmaple, one > change the start hour and the other deletes it) are really close to > 0.0000001%. The question is not how often a conflict happens per day or sync but per 5-years and not for 2 users but for 1000+ users (in the SOGo case many more) which synchronize their 1000+ events when they arrive in the office at 8:30. Now if you are happy you might never encounter a conflict, but keep in mind that PostgreSQL can easily perform 10.000 updates per second on modern hardware so one second of granularity *is* quite broad. Then consider that concurrent changes to a shared item are much more likely than changes to some private, old or new item. This keeps me concerned (but not overly, especially if the users are told about the potential issue). And its really only an issue for large deployments. > So I would not worry about that at all. As mentioned before I think its OK no to worry about it now. But maybe doing it transactionally safe isn't that much harder either? If its too hard to bother, it fine for me. Summary: I'm not exactly pleased about an implementation which relies on timestamps instead of exact states. But I'm even less pleased about not having an implementation at all :-) So, no need to argue any further. I'm fine if you contribute an implementation doing it the way you outlined! Thanks, Helge From developer@opengroupware.org Fri Aug 24 23:15:10 2007 From: developer@opengroupware.org (Wolfgang Sourdeau) Date: Fri, 24 Aug 2007 18:15:10 -0400 Subject: [OGo-Developer] Re: additional field for synchronizatin In-Reply-To: Message-ID: <40c47d221f1ad133df9a83748c5545e0@mozzarella> On 2007-08-24 16:51:12 -0500 Helge Hess wrote: > On 24.08.2007, at 21:55, Wolfgang Sourdeau wrote: >> The chances that 2 users modify the same event (for exmaple, one >> change >> the start hour and the other deletes it) are really close to >> 0.0000001%. > > The question is not how often a conflict happens per day or sync but > per > 5-years and not for 2 users but for 1000+ users (in the SOGo case > many more) > which synchronize their 1000+ events when they arrive in the office > at 8:30. The 2 users on my sample are out of 10000. And this discussion even goes out of its initial purpose. It was mentionned to add a simple c_deleted flag for one event to be able to be synchronied. If you consider a realistic scenario where one event owner out of 100000 users creates and modifies his event in a shared calendar, I don't see how data would get lost. Especially when he deletes it (setting the c_deleted flag to 1). Other users would then have this event disappear of their calendar, unless they modified it (if, in that 0,000001% changes they did it). But if the acls are configured properly (which SOGO has), nobody except the even owner would be allowed to change or delete it... W. From developer@opengroupware.org Fri Aug 24 23:36:27 2007 From: developer@opengroupware.org (Helge Hess) Date: Sat, 25 Aug 2007 00:36:27 +0200 Subject: [OGo-Developer] Re: additional field for synchronizatin In-Reply-To: <40c47d221f1ad133df9a83748c5545e0@mozzarella> References: <40c47d221f1ad133df9a83748c5545e0@mozzarella> Message-ID: On 25.08.2007, at 00:15, Wolfgang Sourdeau wrote: > And this discussion even goes out of its initial purpose. Exactly! I already told you two times that the change is perfectly fine from my point of view?! :-) You made your point clear (a 1s granularity is OK for you) and I made mine (I would prefer an exact state comparison). I just outlined my idea about it so that you can _consider_ it. Thanks, I thought thats why you asked. And again (for a third), I'm fine with going on with the c_deleted thing and a timestamp comparison. > It was mentionned to add a simple c_deleted flag for one event to > be able to be synchronied. Yes, just do it. Common, how often do I need to repeat that I'm fine with your approach? :-) Thanks, Helge PS: so far there is only discussion, when will we actually see the direct Funambol connector in the SOGo-inverse branch? From developer@opengroupware.org Sat Aug 25 00:10:57 2007 From: developer@opengroupware.org (Helge Hess) Date: Sat, 25 Aug 2007 01:10:57 +0200 Subject: [OGo-Developer] multipart/form-data and text encoding In-Reply-To: <2E93BCB1-E593-44C7-B17A-3F3A641F810C@sente.ch> References: <2E93BCB1-E593-44C7-B17A-3F3A641F810C@sente.ch> Message-ID: <7FC71BA6-64E8-4685-BA89-E4E239C3FD47@opengroupware.org> On 23.08.2007, at 19:04, St=E9phane Corth=E9sy wrote: > I think I had the same kind of problem with WebObjects, and solved =20 > it by setting the 'accept-charset' attribute on the form element: =20 > this tells the client to use the passed charset, not a =20 > 'random' (server's POV) one. Hm, actually this maked me wonder whether we should always set the =20 WOForm accept-charset to the response contentEncoding() if not =20 specified otherwise. This would probably make the form behaviour more predictable? Actually: does someone know which browsers submit forms in encodings =20 other than the encoding of the originating HTML page? Thanks, Helge --=20 Helge Hess http://www.helgehess.eu/ From developer@opengroupware.org Wed Aug 29 21:39:49 2007 From: developer@opengroupware.org (Adam Tauno Williams) Date: Wed, 29 Aug 2007 16:39:49 -0400 Subject: [OGo-Developer] Bug#1882 - PEAR XML-RPC is not a recognized user agent Message-ID: <1188419989.5316.10.camel@aleph.wmmi.net> --=-5GQKMOqmX8leJ54iERqW Content-Type: multipart/mixed; boundary="=-x4WMKlFLoszgofhSwZMz" --=-x4WMKlFLoszgofhSwZMz Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Any chance someone can post this patch to SOPE? It resolves - http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=3D1882 - and will get the constant stream of unknown user agent messages out of my logs. :) --=-x4WMKlFLoszgofhSwZMz Content-Disposition: attachment; filename=sopeUA.diff Content-Type: text/x-patch; name=sopeUA.diff; charset=UTF-8 Content-Transfer-Encoding: base64 SW5kZXg6IENoYW5nZUxvZw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0tIENoYW5nZUxvZwkocmV2aXNpb24gMTUy OCkNCisrKyBDaGFuZ2VMb2cJKHdvcmtpbmcgY29weSkNCkBAIC0xLDMgKzEsMTAgQEANCisyMDA3 LTA4LTI5ICBBZGFtIFRhdW5vIFdpbGxpYW1zIDxhd2lsbGlhbUB3aGl0ZW1pY2Vjb25zdWx0aW5n LmNvbT4NCisNCisJKiB2NC43LjEzDQorDQorCSogV0VDbGllbnRDYXBhYmlsaXRpZXMubTogQWRk ZWQgUEVBUiBYTUxfUlBDIGNsaWVudCBhcyBhIGtub3duIHVzZXINCisJICBhZ2VudC4NCisNCiAy MDA3LTA3LTE5ICBNYXJjdXMgTXVlbGxlciAgPHpuZWtAbXVsbGUta3liZXJuZXRpay5jb20+DQog DQogCSogdjQuNy4xMg0KSW5kZXg6IFdFQ2xpZW50Q2FwYWJpbGl0aWVzLm0NCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N Ci0tLSBXRUNsaWVudENhcGFiaWxpdGllcy5tCShyZXZpc2lvbiAxNTI4KQ0KKysrIFdFQ2xpZW50 Q2FwYWJpbGl0aWVzLm0JKHdvcmtpbmcgY29weSkNCkBAIC03Myw2ICs3Myw3IEBADQogI2RlZmlu ZSBXRVVBX0dvb2dsZSAgICAgICAgICAgNDINCiAjZGVmaW5lIFdFVUFfV2ViRHJpdmUgICAgICAg ICA0Mw0KICNkZWZpbmUgV0VVQV9TdW5iaXJkICAgICAgICAgIDQ0DQorI2RlZmluZSBXRVVBX1BF QVJfWE1MUlBDICAgICAgNDUNCiANCiAjZGVmaW5lIFdFT1NfVU5LTk9XTiAgIDANCiAjZGVmaW5l IFdFT1NfV0lORE9XUyAgIDENCkBAIC0zNzQsNiArMzc1LDkgQEANCiAgIGVsc2UgaWYgKHN0cnN0 cih1YSwgIk1lZGlhcGFydG5lcnMtR29vZ2xlLyIpKSB7DQogICAgIHNlbGYtPmJyb3dzZXIgPSBX RVVBX0dvb2dsZTsNCiAgIH0NCisgIGVsc2UgaWYgKHN0cnN0cih1YSwgIlBFQVIgWE1MX1JQQyIp KSB7DQorICAgIHNlbGYtPmJyb3dzZXIgPSBXRVVBX1BFQVJfWE1MUlBDOw0KKyAgfQ0KICAgZWxz ZSB7DQogICAgIC8qIHVua25vd24gYnJvd3NlciAqLw0KICAgICBzZWxmLT5icm93c2VyID0gV0VV QV9VTktOT1dOOw0KQEAgLTQ2OSw2ICs0NzMsNyBAQA0KICAgICBjYXNlIFdFVUFfR29vZ2xlOiAg ICAgICAgICAgcmV0dXJuIEAiR29vZ2xlIjsNCiAgICAgY2FzZSBXRVVBX1dlYkRyaXZlOiAgICAg ICAgIHJldHVybiBAIldlYkRyaXZlIjsNCiAgICAgY2FzZSBXRVVBX1N1bmJpcmQ6ICAgICAgICAg IHJldHVybiBAIlN1bmJpcmQiOw0KKyAgICBjYXNlIFdFVUFfUEVBUl9YTUxSUEM6ICAgICAgcmV0 dXJuIEAiUEhQIFBFQVIgWE1MUlBDIjsNCiAgICAgZGVmYXVsdDogICAgICAgICAgICAgICAgICAg IHJldHVybiBAInVua25vd24iOw0KICAgfQ0KIH0NCkBAIC02MzYsNiArNjQxLDcgQEANCiAgIGlm IChzZWxmLT5icm93c2VyID09IFdFVUFfeG1scnBjbGliX3B5KSByZXR1cm4gWUVTOw0KICAgaWYg KHNlbGYtPmJyb3dzZXIgPT0gV0VVQV9LdW5nTG9nKSAgICAgIHJldHVybiBZRVM7DQogICBpZiAo c2VsZi0+YnJvd3NlciA9PSBXRVVBX0VjdG8pICAgICAgICAgcmV0dXJuIFlFUzsNCisgIGlmIChz ZWxmLT5icm93c2VyID09IFdFVUFfUEVBUl9YTUxSUEMpICByZXR1cm4gWUVTOw0KICAgcmV0dXJu IE5POw0KIH0NCiAtIChCT09MKWlzQkxvZ0NsaWVudCB7DQpAQCAtNzQ2LDYgKzc1Miw5IEBADQog LSAoQk9PTClpc0tvbnF1ZXJvciB7DQogICByZXR1cm4gc2VsZi0+YnJvd3NlciA9PSBXRVVBX0tv bnF1ZXJvciA/IFlFUyA6IE5POw0KIH0NCistIChCT09MKWlzUEhQIHsNCisgIHJldHVybiBzZWxm LWJyb3dzZXIgPT0gV0VVQV9QRUFSX1hNTFJQQyA/IFlFUyA6IE5POw0KK30NCiANCiAvKiBPUyAq Lw0KIA0KSW5kZXg6IFZlcnNpb24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCi0tLSBWZXJzaW9uCShyZXZpc2lvbiAx NTI4KQ0KKysrIFZlcnNpb24JKHdvcmtpbmcgY29weSkNCkBAIC0xLDYgKzEsNiBAQA0KICMgdmVy c2lvbiBmaWxlDQogDQotU1VCTUlOT1JfVkVSU0lPTjo9MTINCitTVUJNSU5PUl9WRVJTSU9OOj0x Mw0KIA0KICMgdjQuNy4xMSAgcmVxdWlyZXMgbGliTkdFeHRlbnNpb25zIHY0LjcuMTk0DQogIyB2 NC41LjIzNCByZXF1aXJlcyBsaWJET00gICAgICAgICAgdjQuNS4yMQ0K --=-x4WMKlFLoszgofhSwZMz-- --=-5GQKMOqmX8leJ54iERqW 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) iD8DBQBG1dmVLRePpNle04MRAu3DAJ9cEa+k+vnz282xav6y/uza7Axs6wCfVBWB 0vRuNo/fnbQJOekXB1AcwtY= =UQ7g -----END PGP SIGNATURE----- --=-5GQKMOqmX8leJ54iERqW-- From developer@opengroupware.org Wed Aug 29 21:45:58 2007 From: developer@opengroupware.org (Adam Tauno Williams) Date: Wed, 29 Aug 2007 16:45:58 -0400 Subject: [OGo-Developer] Bug#1882 - PEAR XML-RPC is not a recognized user agent In-Reply-To: <1188419989.5316.10.camel@aleph.wmmi.net> References: <1188419989.5316.10.camel@aleph.wmmi.net> Message-ID: <1188420358.5316.15.camel@aleph.wmmi.net> --=-VtYSEfH6VGujOW6Lnztu Content-Type: multipart/mixed; boundary="=-OJYh+QvwEGLYH2ZNFHPD" --=-OJYh+QvwEGLYH2ZNFHPD Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2007-08-29 at 16:39 -0400, Adam Tauno Williams wrote: > Any chance someone can post this patch to SOPE? It resolves - > http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=3D1882 > - and will get the constant stream of unknown user agent messages out > of my logs. :) Oops, that patch contains ChangeLog entries and stuff; better use the patch from the bug report. I tried applying the patch then remembered I was in SOPE, not OGo. :) --=-OJYh+QvwEGLYH2ZNFHPD Content-Disposition: attachment; filename=WEClientCapabilities.patch Content-Type: text/x-patch; name=WEClientCapabilities.patch; charset=utf-8 Content-Transfer-Encoding: base64 SW5kZXg6IHNvcGUtYXBwc2VydmVyL05HT2JqV2ViL1dFQ2xpZW50Q2FwYWJpbGl0aWVzLm0NCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCi0tLSBzb3BlLWFwcHNlcnZlci9OR09ialdlYi9XRUNsaWVudENhcGFiaWxpdGll cy5tCShyZXZpc2lvbiAxNTA0KQ0KKysrIHNvcGUtYXBwc2VydmVyL05HT2JqV2ViL1dFQ2xpZW50 Q2FwYWJpbGl0aWVzLm0JKHdvcmtpbmcgY29weSkNCkBAIC03Myw2ICs3Myw3IEBADQogI2RlZmlu ZSBXRVVBX0dvb2dsZSAgICAgICAgICAgNDINCiAjZGVmaW5lIFdFVUFfV2ViRHJpdmUgICAgICAg ICA0Mw0KICNkZWZpbmUgV0VVQV9TdW5iaXJkICAgICAgICAgIDQ0DQorI2RlZmluZSBXRVVBX1BF QVJfWE1MUlBDICAgICAgNDUNCiANCiAjZGVmaW5lIFdFT1NfVU5LTk9XTiAgIDANCiAjZGVmaW5l IFdFT1NfV0lORE9XUyAgIDENCkBAIC0zNzQsNiArMzc1LDkgQEANCiAgIGVsc2UgaWYgKHN0cnN0 cih1YSwgIk1lZGlhcGFydG5lcnMtR29vZ2xlLyIpKSB7DQogICAgIHNlbGYtPmJyb3dzZXIgPSBX RVVBX0dvb2dsZTsNCiAgIH0NCisgIGVsc2UgaWYgKHN0cnN0cih1YSwgIlBFQVIgWE1MX1JQQyIp KSB7DQorICAgIHNlbGYtPmJyb3dzZXIgPSBXRVVBX1BFQVJfWE1MUlBDOw0KKyAgfQ0KICAgZWxz ZSB7DQogICAgIC8qIHVua25vd24gYnJvd3NlciAqLw0KICAgICBzZWxmLT5icm93c2VyID0gV0VV QV9VTktOT1dOOw0KQEAgLTQ2OSw2ICs0NzMsNyBAQA0KICAgICBjYXNlIFdFVUFfR29vZ2xlOiAg ICAgICAgICAgcmV0dXJuIEAiR29vZ2xlIjsNCiAgICAgY2FzZSBXRVVBX1dlYkRyaXZlOiAgICAg ICAgIHJldHVybiBAIldlYkRyaXZlIjsNCiAgICAgY2FzZSBXRVVBX1N1bmJpcmQ6ICAgICAgICAg IHJldHVybiBAIlN1bmJpcmQiOw0KKyAgICBjYXNlIFdFVUFfUEVBUl9YTUxSUEM6ICAgICAgcmV0 dXJuIEAiUEhQIFBFQVIgWE1MUlBDIjsNCiAgICAgZGVmYXVsdDogICAgICAgICAgICAgICAgICAg IHJldHVybiBAInVua25vd24iOw0KICAgfQ0KIH0NCkBAIC02MzYsNiArNjQxLDcgQEANCiAgIGlm IChzZWxmLT5icm93c2VyID09IFdFVUFfeG1scnBjbGliX3B5KSByZXR1cm4gWUVTOw0KICAgaWYg KHNlbGYtPmJyb3dzZXIgPT0gV0VVQV9LdW5nTG9nKSAgICAgIHJldHVybiBZRVM7DQogICBpZiAo c2VsZi0+YnJvd3NlciA9PSBXRVVBX0VjdG8pICAgICAgICAgcmV0dXJuIFlFUzsNCisgIGlmIChz ZWxmLT5icm93c2VyID09IFdFVUFfUEVBUl9YTUxSUEMpICByZXR1cm4gWUVTOw0KICAgcmV0dXJu IE5POw0KIH0NCiAtIChCT09MKWlzQkxvZ0NsaWVudCB7DQpAQCAtNzQ2LDYgKzc1Miw5IEBADQog LSAoQk9PTClpc0tvbnF1ZXJvciB7DQogICByZXR1cm4gc2VsZi0+YnJvd3NlciA9PSBXRVVBX0tv bnF1ZXJvciA/IFlFUyA6IE5POw0KIH0NCistIChCT09MKWlzUEhQIHsNCisgIHJldHVybiBzZWxm LWJyb3dzZXIgPT0gV0VVQV9QRUFSX1hNTFJQQyA/IFlFUyA6IE5POw0KK30NCiANCiAvKiBPUyAq Lw0KIA0K --=-OJYh+QvwEGLYH2ZNFHPD-- --=-VtYSEfH6VGujOW6Lnztu 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) iD8DBQBG1dsGLRePpNle04MRAomIAJ9XrIjVz62LImH3lOp5keYtlWF+QACeM+XX ZBZAYQ0X1sNyeRERreYJzCM= =HDYy -----END PGP SIGNATURE----- --=-VtYSEfH6VGujOW6Lnztu-- From developer@opengroupware.org Wed Aug 29 22:15:42 2007 From: developer@opengroupware.org (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=) Date: Wed, 29 Aug 2007 23:15:42 +0200 Subject: [OGo-Developer] multipart/form-data and text encoding In-Reply-To: <7FC71BA6-64E8-4685-BA89-E4E239C3FD47@opengroupware.org> References: <2E93BCB1-E593-44C7-B17A-3F3A641F810C@sente.ch> <7FC71BA6-64E8-4685-BA89-E4E239C3FD47@opengroupware.org> Message-ID: On Aug 25, 2007, at 1:10 AM, Helge Hess wrote: > On 23.08.2007, at 19:04, St=E9phane Corth=E9sy wrote: >> I think I had the same kind of problem with WebObjects, and solved =20= >> it by setting the 'accept-charset' attribute on the form element: =20 >> this tells the client to use the passed charset, not a =20 >> 'random' (server's POV) one. > > Hm, actually this maked me wonder whether we should always set the =20 > WOForm accept-charset to the response contentEncoding() if not =20 > specified otherwise. > This would probably make the form behaviour more predictable? That is a good idea. > Actually: does someone know which browsers submit forms in =20 > encodings other than the encoding of the originating HTML page? IIRC, I had troubles with Windows IE 6, which was sending me some =20 Windows Latin1 chars which are not in ISOLatin1 table (some quote =20 character). I think some clients use their system default encoding: =20 WinLatin1 from Windows, MacOSRoman from MacOS 9. St=E9phane > Thanks, > Helge > --=20 > Helge Hess > http://www.helgehess.eu/ > > > -- > OpenGroupware.org Developer > developer@opengroupware.org > http://mail.opengroupware.org/mailman/listinfo/developer From developer@opengroupware.org Thu Aug 30 15:03:25 2007 From: developer@opengroupware.org (=?ISO-8859-1?Q?Marcus_M=FCller?=) Date: Thu, 30 Aug 2007 16:03:25 +0200 Subject: [OGo-Developer] zOGI uploaded [Was: Re: Consonance Snapshot] In-Reply-To: <1187704444.5045.4.camel@aleph.wmmi.net> References: <1186434006.4519.2.camel@aleph.whitemice.org> <6AE0AEC7-553C-4D5B-B1BB-2372ED7DC76B@opengroupware.org> <1187546475.4256.3.camel@aleph.wmmi.net> <7AB6DBCC-4B40-4B31-A928-01B6FFB473A0@opengroupware.org> <1187704444.5045.4.camel@aleph.wmmi.net> Message-ID: <178BDA3C-A1E3-4FC6-B5CC-8C0D51957032@mulle-kybernetik.com> --Apple-Mail-17--277991855 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > Maybe I did miss something; entries in the ChangeLog don't appear on > the ChangeBlogger. It is OK with me if they aren't supposed to, it > just > made me wonder. Ooops, sorry - totally overlooked your post. I have to add all ChangeLogs manually into the ChangeBlogger's config. Should I add the zOGI ChangeLog? Perhaps anything else missing which should also be listed? Cheers, Marcus -- Marcus Mueller . . . crack-admin/coder ;-) Mulle kybernetiK . http://www.mulle-kybernetik.com Current projects: http://www.mulle-kybernetik.com/znek/ --Apple-Mail-17--277991855 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Maybe I did = miss something;=A0 entries = in the ChangeLog don't appear on
the = ChangeBlogger.=A0 It is OK = with me if they aren't supposed to, it just
made me = wonder.

Ooops, sorry - totally = overlooked your post. I have to add all ChangeLogs manually into the = ChangeBlogger's config. Should I add the zOGI ChangeLog? Perhaps = anything else missing which should also be listed?

Cheers,


=A0=A0Marcus


--=A0

Marcus Mueller=A0=A0.=A0=A0.=A0=A0.=A0=A0crack-admin/coder = ;-)

Mulle = kybernetiK=A0=A0.=A0=A0http://www.mulle-kybernetik.com

Current = projects:=A0http://www.mulle-kybernetik= .com/znek/


 =

= --Apple-Mail-17--277991855-- From developer@opengroupware.org Thu Aug 30 15:18:36 2007 From: developer@opengroupware.org (Adam Tauno Williams) Date: Thu, 30 Aug 2007 10:18:36 -0400 Subject: [OGo-Developer] zOGI uploaded [Was: Re: Consonance Snapshot] In-Reply-To: <178BDA3C-A1E3-4FC6-B5CC-8C0D51957032@mulle-kybernetik.com> References: <1186434006.4519.2.camel@aleph.whitemice.org> <6AE0AEC7-553C-4D5B-B1BB-2372ED7DC76B@opengroupware.org> <1187546475.4256.3.camel@aleph.wmmi.net> <7AB6DBCC-4B40-4B31-A928-01B6FFB473A0@opengroupware.org> <1187704444.5045.4.camel@aleph.wmmi.net> <178BDA3C-A1E3-4FC6-B5CC-8C0D51957032@mulle-kybernetik.com> Message-ID: <1188483516.5274.50.camel@aleph.wmmi.net> --=-kIgdpLiFcWM4W7Hjob2Z Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > > Maybe I did miss something; entries in the ChangeLog don't appear > > on the ChangeBlogger. It is OK with me if they aren't supposed to, > > it just made me wonder > Ooops, sorry - totally overlooked your post. I have to add all > ChangeLogs manually into the ChangeBlogger's config. Should I add the > zOGI ChangeLog?=20 I'd like this, yes. > Perhaps anything else missing which should also be listed? I haven't noticed anything else that doesn't show up. --=-kIgdpLiFcWM4W7Hjob2Z 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) iD8DBQBG1tG8LRePpNle04MRAvb9AJsH6JNkhFvoKL68rOlvA1tTGa5wiQCdE0en sx60K2WA0uA/cj6MwQTtyJg= =C0Ly -----END PGP SIGNATURE----- --=-kIgdpLiFcWM4W7Hjob2Z--