From developer@opengroupware.org  Thu Mar 13 16:22:10 2008
From: developer@opengroupware.org (Jeff)
Date: Thu, 13 Mar 2008 12:22:10 -0400
Subject: [OGo-Developer] Appointment Type dropdown
Message-ID: <be0073cd0803130922j36d9d431u793689c88b5034e6@mail.gmail.com>

------=_Part_15681_10118950.1205425330588
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Is there a reliable way to identify the appointment type dropdown in the
Appointment Editor?

I want to just add a real quick check in the
LSWAppointmentEditor.jsvalidateEditorContent() routine to throw an
error if the selection is = 0
(none).

But the name changes with each load - but is there some way I can build the
name of the dropdown in validateEditorContent?

Thanks,
Jeff

------=_Part_15681_10118950.1205425330588
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br>Is there a reliable way to identify the appointment type dropdown in the Appointment Editor?<br><br>I want to just add a real quick check in the LSWAppointmentEditor.js validateEditorContent() routine to throw an error if the selection is = 0 (none).<br>
<br>But the name changes with each load - but is there some way I can build the name of the dropdown in validateEditorContent?<br><br>Thanks,<br>Jeff<br><br>

------=_Part_15681_10118950.1205425330588--

From developer@opengroupware.org  Thu Mar 13 16:34:42 2008
From: developer@opengroupware.org (Jeff)
Date: Thu, 13 Mar 2008 12:34:42 -0400
Subject: [OGo-Developer] Re: Appointment Type dropdown
In-Reply-To: <be0073cd0803130922j36d9d431u793689c88b5034e6@mail.gmail.com>
References: <be0073cd0803130922j36d9d431u793689c88b5034e6@mail.gmail.com>
Message-ID: <be0073cd0803130934u1c3fc047i30654c6eb2cd2542@mail.gmail.com>

------=_Part_15827_10017053.1205426082880
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I think I found a way to do it, but just wanted to check to make sure this
would be reliable:

If I get the text at the end of the URL for the form action, and append
".2.1.1.12.1.0.1" to it, that appears to be the appointment type dropdown.

Is that something that could change though?  Or is there a better method
than what I'm proposing?

Thanks!
Jeff

On Thu, Mar 13, 2008 at 12:22 PM, Jeff <jhedlund+ogo@gmail.com> wrote:

>
> Is there a reliable way to identify the appointment type dropdown in the
> Appointment Editor?
>
> I want to just add a real quick check in the LSWAppointmentEditor.jsvalidateEditorContent() routine to throw an error if the selection is = 0
> (none).
>
> But the name changes with each load - but is there some way I can build
> the name of the dropdown in validateEditorContent?
>
> Thanks,
> Jeff
>
>

------=_Part_15827_10017053.1205426082880
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br>I think I found a way to do it, but just wanted to check to make sure this would be reliable:<br><br>If I get the text at the end of the URL for the form action, and append &quot;.2.1.1.12.1.0.1&quot; to it, that appears to be the appointment type dropdown.<br>
<br>Is that something that could change though?&nbsp; Or is there a better method than what I&#39;m proposing?<br><br>Thanks!<br>Jeff<br><br><div class="gmail_quote">On Thu, Mar 13, 2008 at 12:22 PM, Jeff &lt;<a href="mailto:jhedlund+ogo@gmail.com">jhedlund+ogo@gmail.com</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Is there a reliable way to identify the appointment type dropdown in the Appointment Editor?<br>
<br>I want to just add a real quick check in the LSWAppointmentEditor.js validateEditorContent() routine to throw an error if the selection is = 0 (none).<br>
<br>But the name changes with each load - but is there some way I can build the name of the dropdown in validateEditorContent?<br><br>Thanks,<br><font color="#888888">Jeff<br><br>
</font></blockquote></div><br>

------=_Part_15827_10017053.1205426082880--

From developer@opengroupware.org  Thu Mar 13 16:41:43 2008
From: developer@opengroupware.org (Helge Hess)
Date: Thu, 13 Mar 2008 17:41:43 +0100
Subject: [OGo-Developer] Re: Appointment Type dropdown
In-Reply-To: <be0073cd0803130934u1c3fc047i30654c6eb2cd2542@mail.gmail.com>
References: <be0073cd0803130922j36d9d431u793689c88b5034e6@mail.gmail.com> <be0073cd0803130934u1c3fc047i30654c6eb2cd2542@mail.gmail.com>
Message-ID: <064830DD-D245-4BD8-9628-0DDA735ED613@opengroupware.org>

On 13.03.2008, at 17:34, Jeff wrote:
> I think I found a way to do it, but just wanted to check to make  
> sure this would be reliable:
>
> If I get the text at the end of the URL for the form action, and  
> append ".2.1.1.12.1.0.1" to it, that appears to be the appointment  
> type dropdown.
>
> Is that something that could change though?  Or is there a better  
> method than what I'm proposing?


No, element-ids are automatically generated and may change. It really  
depends on the form/component, you would usually want to assign a  
static id/value if its not a reusable component.
The WOPopUpButton documentation might help you to get started.

Greets,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/

From developer@opengroupware.org  Thu Mar 13 16:59:17 2008
From: developer@opengroupware.org (Jeff)
Date: Thu, 13 Mar 2008 12:59:17 -0400
Subject: [OGo-Developer] Re: Appointment Type dropdown
In-Reply-To: <064830DD-D245-4BD8-9628-0DDA735ED613@opengroupware.org>
References: <be0073cd0803130922j36d9d431u793689c88b5034e6@mail.gmail.com>
 <be0073cd0803130934u1c3fc047i30654c6eb2cd2542@mail.gmail.com>
 <064830DD-D245-4BD8-9628-0DDA735ED613@opengroupware.org>
Message-ID: <be0073cd0803130959v270fa112h9f52b3fad7d92833@mail.gmail.com>

------=_Part_16009_2785211.1205427557958
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On Thu, Mar 13, 2008 at 12:41 PM, Helge Hess <helge.hess@opengroupware.org>
wrote:

> No, element-ids are automatically generated and may change. It really
> depends on the form/component, you would usually want to assign a
> static id/value if its not a reusable component.
> The WOPopUpButton documentation might help you to get started.
>
>
Thanks - I'll take a look at that.

If I change a wod file, do I have to recompile or just restart ogo?

Thanks,
Jeff

------=_Part_16009_2785211.1205427557958
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br><br><div class="gmail_quote">On Thu, Mar 13, 2008 at 12:41 PM, Helge Hess &lt;<a href="mailto:helge.hess@opengroupware.org">helge.hess@opengroupware.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
No, element-ids are automatically generated and may change. It really<br>
depends on the form/component, you would usually want to assign a<br>
static id/value if its not a reusable component.<br>
The WOPopUpButton documentation might help you to get started.<br><br></blockquote><div><br>Thanks - I&#39;ll take a look at that.<br><br>If I change a wod file, do I have to recompile or just restart ogo?<br><br>Thanks,<br>
Jeff<br>
&nbsp;</div></div>

------=_Part_16009_2785211.1205427557958--

From developer@opengroupware.org  Thu Mar 13 17:07:11 2008
From: developer@opengroupware.org (Helge Hess)
Date: Thu, 13 Mar 2008 18:07:11 +0100
Subject: [OGo-Developer] Re: Appointment Type dropdown
In-Reply-To: <be0073cd0803130959v270fa112h9f52b3fad7d92833@mail.gmail.com>
References: <be0073cd0803130922j36d9d431u793689c88b5034e6@mail.gmail.com> <be0073cd0803130934u1c3fc047i30654c6eb2cd2542@mail.gmail.com> <064830DD-D245-4BD8-9628-0DDA735ED613@opengroupware.org> <be0073cd0803130959v270fa112h9f52b3fad7d92833@mail.gmail.com>
Message-ID: <23775550-9E43-4DC5-B169-FDC7E63257BD@opengroupware.org>

On 13.03.2008, at 17:59, Jeff wrote:
> If I change a wod file, do I have to recompile or just restart ogo?


Just restart.

Greets,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/

From developer@opengroupware.org  Thu Mar 20 12:22:12 2008
From: developer@opengroupware.org (Kit)
Date: Thu, 20 Mar 2008 14:22:12 +0200
Subject: [OGo-Developer] OGo-1.0 Installation error
Message-ID: <20080320135335.4304.FB146962@infocom.ua>

I've got:

PPSyncContext.m: In function '-[PPSyncContext
fetchRecordByID:fromDatabase:attributes:category:]':
PPSyncContext.m:974: warning: passing argument 4 of 'dlp_ReadRecordById' from incompatible pointer type
PPSyncContext.m:974: error: too many arguments to function 'dlp_ReadRecordById'
make[3]: *** [shared_debug_obj/PPSyncContext.o] Error 1
make[2]: *** [libPPSync.all.library.variables] Error 2
make[2]: Leaving directory `/usr/install/OpenGroupware/OGo-1.0/PDA/PPSync'
make[1]: *** [internal-all] Error 2
make[1]: Leaving directory `/usr/install/OpenGroupware/OGo-1.0/PDA'
make: *** [internal-all] Error 2

Anyone can help me ?

System
 cat /etc/issue
Mandriva Linux release 2008.0 (Official) for i586
Kernel 2.6.22.18-desktop-1mdv on an i686 / \l-- 

Thanx
Kit <kit@infocom.ua>


From developer@opengroupware.org  Thu Mar 20 12:58:01 2008
From: developer@opengroupware.org (Adam Tauno Williams)
Date: Thu, 20 Mar 2008 08:58:01 -0400
Subject: [OGo-Developer] OGo-1.0 Installation error
In-Reply-To: <20080320135335.4304.FB146962@infocom.ua>
References: <20080320135335.4304.FB146962@infocom.ua>
Message-ID: <1206017881.5173.6.camel@WM_ADAM1.morrison.iserv.net>

On Thu, 2008-03-20 at 14:22 +0200, Kit wrote:
> I've got:
> 
> PPSyncContext.m: In function '-[PPSyncContext
> fetchRecordByID:fromDatabase:attributes:category:]':
> PPSyncContext.m:974: warning: passing argument 4 of 'dlp_ReadRecordById' from incompatible pointer type
> PPSyncContext.m:974: error: too many arguments to function 'dlp_ReadRecordById'
> make[3]: *** [shared_debug_obj/PPSyncContext.o] Error 1
> make[2]: *** [libPPSync.all.library.variables] Error 2
> make[2]: Leaving directory `/usr/install/OpenGroupware/OGo-1.0/PDA/PPSync'
> make[1]: *** [internal-all] Error 2
> make[1]: Leaving directory `/usr/install/OpenGroupware/OGo-1.0/PDA'
> make: *** [internal-all] Error 2
> Anyone can help me ?

You have an incompatible pilot-link version.  Unfortunately the
pilot-link API changed, and PalmOS 4 vs 5 databases are not compatible,
etc...

I strongly suggest to build with "--without-pisock" which disables the
PDA (Palm OS) module. See -
<http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1638>
<http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1811>
 - if you are interesting in digging into the issue.  

The "--without-pisock" option is mentioned in the installation section
of WMOGAG <http://www.whitemiceconsulting.com/node/67> or
<http://docs.opengroupware.org/Members/whitemice/wmogag/file_view>

My build from source procedure is at
<http://www.whitemiceconsulting.com/node/144>


From developer@opengroupware.org  Thu Mar 20 12:55:13 2008
From: developer@opengroupware.org (Helge Hess)
Date: Thu, 20 Mar 2008 13:55:13 +0100
Subject: [OGo-Developer] OGo-1.0 Installation error
In-Reply-To: <20080320135335.4304.FB146962@infocom.ua>
References: <20080320135335.4304.FB146962@infocom.ua>
Message-ID: <CF4B2D00-58A3-4F6B-BA58-B7BCE740FA50@opengroupware.org>

Hi,

please write to the users@ogo mailinglist for installation support.  
You most likely need to deactivate the Palm support, if you don't know  
how, ask on the users list.
Finally, use OGo 1.1.7, not 1.0 which is rather ancient now.

Thanks,
   Helge

On 20.03.2008, at 13:22, Kit wrote:
> I've got:
>
> PPSyncContext.m: In function '-[PPSyncContext
> fetchRecordByID:fromDatabase:attributes:category:]':
> PPSyncContext.m:974: warning: passing argument 4 of  
> 'dlp_ReadRecordById' from incompatible pointer type
> PPSyncContext.m:974: error: too many arguments to function  
> 'dlp_ReadRecordById'
> make[3]: *** [shared_debug_obj/PPSyncContext.o] Error 1
> make[2]: *** [libPPSync.all.library.variables] Error 2
> make[2]: Leaving directory `/usr/install/OpenGroupware/OGo-1.0/PDA/ 
> PPSync'
> make[1]: *** [internal-all] Error 2
> make[1]: Leaving directory `/usr/install/OpenGroupware/OGo-1.0/PDA'
> make: *** [internal-all] Error 2
>
> Anyone can help me ?
>
> System
> cat /etc/issue
> Mandriva Linux release 2008.0 (Official) for i586
> Kernel 2.6.22.18-desktop-1mdv on an i686 / \l--
>
> Thanx
> Kit <kit@infocom.ua>

-- 
Helge Hess
http://www.helgehess.eu/

From developer@opengroupware.org  Tue Mar 25 20:44:31 2008
From: developer@opengroupware.org (Helge Hess)
Date: Tue, 25 Mar 2008 21:44:31 +0100
Subject: [OGo-Developer] JOPE now Go, on GoogleCode
Message-ID: <296687E6-50F2-4472-8422-A84C1735C825@opengroupware.org>

Hi,

to check out the viability of GoogleCode, I have moved the JOPE  
repository there. In the same run I renamed it to GETobjects, aka Go :-)
(like in O..Go). If it works well, I will also checkin the OGoCore  
Java stuff into GoogleCode. Maybe even SOPE, OGo, SOGo as well. We'll  
see.
All this should take some load from the OGo server machines and  
improve reliability. We even get a Wiki ;-)

Greets,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/

From developer@opengroupware.org  Wed Mar 26 17:18:51 2008
From: developer@opengroupware.org (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=)
Date: Wed, 26 Mar 2008 18:18:51 +0100
Subject: [OGo-Developer] Bugs in mod_ngobjweb
Message-ID: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch>

Hi,

I found bugs in mod_ngobjweb:

In NGBufferedDescriptor.c, at the beginning of =20
NGBufferedDescriptor_read(), availBytes is initialized by =20
numberOfAvailableReadBufferBytes(self), whereas the test "if(self =3D=3D =
=20
NULL)" is done later; this could crash. BTW, =20
numberOfAvailableReadBufferBytes(self) should be called only just =20
before "if (availBytes >=3D _len)".

In handler.c:
Around line 721, after NGBufferedDescriptor_safeRead(), you free =20
'toApp', but don't NULLify it, and some lines later the pointer is =20
freed again when not NULL.
BTW, there is a "#if HEAVY_LOG" whereas everywhere else you use "if=20
(HEAVY_LOG)".


I encountered several bugs with this module, when using WOFileUpload. =20=

I hope these fixes are enough.

Cheers,

St=E9phane


From developer@opengroupware.org  Wed Mar 26 18:54:41 2008
From: developer@opengroupware.org (Helge Hess)
Date: Wed, 26 Mar 2008 19:54:41 +0100
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch>
References: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch>
Message-ID: <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org>

On 26.03.2008, at 18:18, St=E9phane Corth=E9sy wrote:
> I found bugs in mod_ngobjweb:
>
> In NGBufferedDescriptor.c, at the beginning of =20
> NGBufferedDescriptor_read(), availBytes is initialized by =20
> numberOfAvailableReadBufferBytes(self), whereas the test "if(self =3D=3D=
 =20
> NULL)" is done later; this could crash. BTW, =20
> numberOfAvailableReadBufferBytes(self) should be called only just =20
> before "if (availBytes >=3D _len)".
>
> In handler.c:
> Around line 721, after NGBufferedDescriptor_safeRead(), you free =20
> 'toApp', but don't NULLify it, and some lines later the pointer is =20
> freed again when not NULL.
> BTW, there is a "#if HEAVY_LOG" whereas everywhere else you use =20
> "if(HEAVY_LOG)".


Thanks, the two things are committed (r1619).

BTW: technically its possible to use mod_proxy of Apache 2.2 with =20
SOPE, it has plenty of options to downgrade the HTTP connection for =20
the proxied backend.

The biggest issue is that there is no non-streaming mode (which blocks =20=

the appserver on remote IO), but maybe this can be emulated somehow by =20=

configuring very large HTTP buffers.

Eg:
---snip---
ProxyRequests     Off   # no forward proxy, only reverse
ProxyPreserveHost On    # Apache 2.0.31 and later
ProxyVia          block
ProxyBadHeader StartBody

<Location /zidestore>
ProxyPass        http://127.0.0.1:21000/zidestore
ProxyPassReverse http://127.0.0.1:21000/zidestore
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive       1
</Location>
---snap---

Greets,
   Helge
--=20
Helge Hess
http://www.helgehess.eu/=

From developer@opengroupware.org  Thu Mar 27 08:49:06 2008
From: developer@opengroupware.org (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=)
Date: Thu, 27 Mar 2008 09:49:06 +0100
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org>
References: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch> <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org>
Message-ID: <C8AFCF45-05CB-46BE-BDC1-18499E49CCB3@sente.ch>

Hi,

On Mar 26, 2008, at 7:54 PM, Helge Hess wrote:

> On 26.03.2008, at 18:18, St=E9phane Corth=E9sy wrote:
>> I found bugs in mod_ngobjweb:
>>
>> In NGBufferedDescriptor.c, at the beginning of =20
>> NGBufferedDescriptor_read(), availBytes is initialized by =20
>> numberOfAvailableReadBufferBytes(self), whereas the test "if(self =20
>> =3D=3D NULL)" is done later; this could crash. BTW, =20
>> numberOfAvailableReadBufferBytes(self) should be called only just =20
>> before "if (availBytes >=3D _len)".
>>
>> In handler.c:
>> Around line 721, after NGBufferedDescriptor_safeRead(), you free =20
>> 'toApp', but don't NULLify it, and some lines later the pointer is =20=

>> freed again when not NULL.
>> BTW, there is a "#if HEAVY_LOG" whereas everywhere else you use "if=20=

>> (HEAVY_LOG)".
>
>
> Thanks, the two things are committed (r1619).
>
> BTW: technically its possible to use mod_proxy of Apache 2.2 with =20
> SOPE, it has plenty of options to downgrade the HTTP connection for =20=

> the proxied backend.
>
> The biggest issue is that there is no non-streaming mode (which =20
> blocks the appserver on remote IO), but maybe this can be emulated =20
> somehow by configuring very large HTTP buffers.


Does this mean that mod_ngobjweb does not support file upload?
I know very little about apache, bear with me.
Currently I have this config:

         <LocationMatch "^/PPUREdit*">
                 SetHandler ngobjweb-adaptor
                 SetAppPort 20000
         </LocationMatch>

Am I supposed to change it to

         <LocationMatch "^/PPUREdit*">
                 SetHandler ngobjweb-adaptor
                 SetAppPort 20000
ProxyPass        http://127.0.0.1:20000/PPUREdit
ProxyPassReverse http://127.0.0.1:20000/PPUREdit
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive       1

         </LocationMatch>

St=E9phane

> Eg:
> ---snip---
> ProxyRequests     Off   # no forward proxy, only reverse
> ProxyPreserveHost On    # Apache 2.0.31 and later
> ProxyVia          block
> ProxyBadHeader StartBody
>
> <Location /zidestore>
> ProxyPass        http://127.0.0.1:21000/zidestore
> ProxyPassReverse http://127.0.0.1:21000/zidestore
> SetEnv force-proxy-request-1.0 1
> SetEnv proxy-nokeepalive       1
> </Location>
> ---snap---
>
> Greets,
>   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 Mar 27 09:15:37 2008
From: developer@opengroupware.org (Helge Hess)
Date: Thu, 27 Mar 2008 10:15:37 +0100
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: <C8AFCF45-05CB-46BE-BDC1-18499E49CCB3@sente.ch>
References: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch> <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org> <C8AFCF45-05CB-46BE-BDC1-18499E49CCB3@sente.ch>
Message-ID: <625BE739-2A5A-4D29-BCDE-5DBDE0FD78A4@opengroupware.org>

On 27.03.2008, at 09:49, St=E9phane Corth=E9sy wrote:
> Does this mean that mod_ngobjweb does not support file upload?

Sure it does (and its used that way a lot in OGo, not exactly sure why =20=

you are experiencing issues).

> I know very little about apache, bear with me.
> Currently I have this config:

Hm, no, you either use mod_ngobjweb OR mod_proxy :-)


OK, back to the start ;-) What is mod_ngobjweb. Its
a) a non-streaming proxy
b) a protocol downgrader
c) a load balancer which works in combination with snsd
You usually don't care about c).

a) means that mod_ngobjweb collects the whole HTTP requests sent by =20
the browser before it transfers it to the SOPE application. This =20
removes the browser<->WAN<->Server latency/slowness towards the app. =20
Which is important because the SOPE app is non-threaded (and doesn't =20
use non-blocking-IO for reading requests), hence it should not block =20
on IO.

b) is basically the reason why you could not use Apache mod_proxy as a =20=

SOPE frontend, even if you don't care about issue a). SOPE =20
applications are not fully conforming HTTP servers, especially not =20
HTTP/1.1 ones. Therefore Apache is used in front, which does all the =20
HTTP heavy-lifting. mod_ngobjweb then talks HTTP/1.0 w/o keepalive etc =20=

to the SOPE app.
Now the new thing (and that was my comment in the last mail) is, that =20=

mod_proxy can now also do the downgrade for 'b0rked' HTTP backend =20
servers.

Why would you want to use mod_proxy. Well, it comes preinstalled with =20=

every Apache and its of course much more stable :-)
Not sure yet how to resolve a) though.


Summary for you: you probably want to ignore all that and continue =20
fixing your specific mod_ngobjweb problem :-)

Greets,
   Helge
--=20
Helge Hess
http://www.helgehess.eu/=

From developer@opengroupware.org  Thu Mar 27 10:16:05 2008
From: developer@opengroupware.org (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=)
Date: Thu, 27 Mar 2008 11:16:05 +0100
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: <625BE739-2A5A-4D29-BCDE-5DBDE0FD78A4@opengroupware.org>
References: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch> <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org> <C8AFCF45-05CB-46BE-BDC1-18499E49CCB3@sente.ch> <625BE739-2A5A-4D29-BCDE-5DBDE0FD78A4@opengroupware.org>
Message-ID: <CBE2DBF5-1FE4-4025-BDC8-B5462CF46495@sente.ch>

Hi,

I'm getting more and more confused :-(

On Mar 27, 2008, at 10:15 AM, Helge Hess wrote:

> On 27.03.2008, at 09:49, St=E9phane Corth=E9sy wrote:
>> Does this mean that mod_ngobjweb does not support file upload?
>
> Sure it does (and its used that way a lot in OGo, not exactly sure =20
> why you are experiencing issues).


OK, so that's good news.
Precisely, I used WOFileUpload, and mod_ngobjweb on apache 2.2.6/OSX =20
10.5.2 Server. Most of the time users can't upload files with Safari; =20=

repeating the operation with the same file always fails: Safari sends =20=

file, and waits forever.
I noticed the httpd crashed sometimes, in mod_ngobjweb code, or, =20
worse, becomes completely crazy and eats all memory and CPU!
The same files passed via Firefox work. I don't know whether it's =20
100% success, though.


>> I know very little about apache, bear with me.
>> Currently I have this config:
>
> Hm, no, you either use mod_ngobjweb OR mod_proxy :-)
>
>
> OK, back to the start ;-) What is mod_ngobjweb. Its
> a) a non-streaming proxy
> b) a protocol downgrader
> c) a load balancer which works in combination with snsd
> You usually don't care about c).
>
> a) means that mod_ngobjweb collects the whole HTTP requests sent by =20=

> the browser before it transfers it to the SOPE application. This =20
> removes the browser<->WAN<->Server latency/slowness towards the =20
> app. Which is important because the SOPE app is non-threaded (and =20
> doesn't use non-blocking-IO for reading requests), hence it should =20
> not block on IO.
>
> b) is basically the reason why you could not use Apache mod_proxy =20
> as a SOPE frontend, even if you don't care about issue a). SOPE =20
> applications are not fully conforming HTTP servers, especially not =20
> HTTP/1.1 ones. Therefore Apache is used in front, which does all =20
> the HTTP heavy-lifting. mod_ngobjweb then talks HTTP/1.0 w/o =20
> keepalive etc to the SOPE app.
> Now the new thing (and that was my comment in the last mail) is, =20
> that mod_proxy can now also do the downgrade for 'b0rked' HTTP =20
> backend servers.
>
> Why would you want to use mod_proxy. Well, it comes preinstalled =20
> with every Apache and its of course much more stable :-)
> Not sure yet how to resolve a) though.


Question is: would it work to use mod_proxy?

> Summary for you: you probably want to ignore all that and continue =20
> fixing your specific mod_ngobjweb problem :-)


Hhm, well... Any clue on what's wrong with the module?

Here's the latest crash (this morning); module had the fixes I sent you.

Thread 0 Crashed:
0   libaprutil-1.0.dylib                0x00069218 apr_brigade_create =20=

+ 42
1   httpd                               0x0002dcdd =20
ap_get_client_block + 98
2   mod_ngobjweb.so                     0x003b1a77 _readRequestBody + =20=

269
3   mod_ngobjweb.so                     0x003b230c ngobjweb_handler + =20=

502
4   httpd                               0x00002182 ap_run_handler + 70
5   httpd                               0x000028cf ap_invoke_handler =20
+ 316
6   httpd                               0x0002a4e0 ap_process_request =20=

+ 101
7   httpd                               0x00026eb6 =20
ap_process_http_connection + 113
8   httpd                               0x00011055 =20
ap_run_process_connection + 70
9   httpd                               0x0001146f =20
ap_process_connection + 81
10  httpd                               0x000308c6 child_main + 1169
11  httpd                               0x00030aae make_child + 384
12  httpd                               0x00030d11 =20
perform_idle_server_maintenance + 480
13  httpd                               0x0003125d ap_mpm_run + 1285
14  httpd                               0x0000962b main + 2969
15  httpd                               0x000018f6 start + 54


St=E9phane


> Greets,
>   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 Mar 27 11:11:22 2008
From: developer@opengroupware.org (Helge Hess)
Date: Thu, 27 Mar 2008 12:11:22 +0100
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: <CBE2DBF5-1FE4-4025-BDC8-B5462CF46495@sente.ch>
References: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch> <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org> <C8AFCF45-05CB-46BE-BDC1-18499E49CCB3@sente.ch> <625BE739-2A5A-4D29-BCDE-5DBDE0FD78A4@opengroupware.org> <CBE2DBF5-1FE4-4025-BDC8-B5462CF46495@sente.ch>
Message-ID: <D6F8C332-73DC-4411-A17E-DDCD97906A27@opengroupware.org>

On 27.03.2008, at 11:16, St=E9phane Corth=E9sy wrote:
> I'm getting more and more confused :-(

Sorry :-)

>> Sure it does (and its used that way a lot in OGo, not exactly sure =20=

>> why you are experiencing issues).
> OK, so that's good news.
> Precisely, I used WOFileUpload, and mod_ngobjweb on apache 2.2.6/OSX =20=

> 10.5.2 Server.

How did you get mod_ngobjweb to compile on 10.5.x? I didn't manage =20
that :-/

Maybe your problems are due to an 64bit issue? Might be possible that =20=

mod_ngobjweb has bugs here.

> Most of the time users can't upload files with Safari; repeating the =20=

> operation with the same file always fails: Safari sends file, and =20
> waits forever.
> I noticed the httpd crashed sometimes, in mod_ngobjweb code, or, =20
> worse, becomes completely crazy and eats all memory and CPU!

I've never seen that behaviour. Maybe Safari does HTTP pipelining or =20
something like that, which in turn might confuse Apache/mod_ngobjweb. =20=

No idea, really.

> Question is: would it work to use mod_proxy?

Yes, it should work with mod_proxy. Its has the disadvantage that your =20=

app blocks on IO while the file is being uploaded. But maybe thats not =20=

a big problem for your app (certainly better than not-working-at-=20
all ;-).

> Hhm, well... Any clue on what's wrong with the module?
>
> Here's the latest crash (this morning); module had the fixes I sent =20=

> you.
>
> Thread 0 Crashed:
> 0   libaprutil-1.0.dylib                0x00069218 =20
> apr_brigade_create + 42
> 1   httpd                               0x0002dcdd =20
> ap_get_client_block + 98
> 2   mod_ngobjweb.so                     0x003b1a77 _readRequestBody =20=

> + 269

My best guess is 64bit issue or some 10.5.x incompatibility. Or some =20
Apache 2.2 incompat. Don't know.

Maybe you should just go for mod_proxy in this kind of setup (thats =20
what I use for 10.5 development too). Drop mod_ngobjweb from your =20
Apache configuration, add mod_proxy and use the config section I =20
showed in one of the previous mails.

Greets,
   Helge

PS: the real solution would be to write a threaded/nio WOHttpAdaptor. =20=

Thats what WebObjects did too (request processing would be done =20
multithreaded, but -dispatchRequest: would still be single threaded).
--=20
Helge Hess
http://www.helgehess.eu/=

From developer@opengroupware.org  Thu Mar 27 12:45:48 2008
From: developer@opengroupware.org (Sebastian Reitenbach)
Date: Thu, 27 Mar 2008 13:45:48 +0100
Subject: [OGo-Developer] Bugs in mod_ngobjweb
Message-ID: <20080327124550.0089585FFB@smtp.l00-bugdead-prods.de>

developer@opengroupware.org wrote: 
> Hi,
> 
> I'm getting more and more confused :-(
> 
> On Mar 27, 2008, at 10:15 AM, Helge Hess wrote:
> 
> > On 27.03.2008, at 09:49, St=E9phane Corth=E9sy wrote:
> >> Does this mean that mod_ngobjweb does not support file upload?
> >
> > Sure it does (and its used that way a lot in OGo, not exactly sure  
> > why you are experiencing issues).
> 
> 
> OK, so that's good news.
> Precisely, I used WOFileUpload, and mod_ngobjweb on apache 2.2.6/OSX  
> 10.5.2 Server. Most of the time users can't upload files with Safari;  
repeating the operation with the same file always fails: Safari sends  file, 
and waits forever.
> I noticed the httpd crashed sometimes, in mod_ngobjweb code, or,  
> worse, becomes completely crazy and eats all memory and CPU!
I've seen httpd crashes too, but I am not sure, whether they happen in the 
mod_ngobjweb module. I've also seen apache eating all CPU and Memory.
I'm on sles10sp1 x86_64, with ogo/mod_ngobjweb installed as 64Bit versions.

But I am still unable to reproduce the issue, as they seem to 
happen "randomly". Most of the users use Konqueror, or Firefox.

But if I remember correctly, many of these eating all CPU/Memory happens 
when uploading files or mail attachements.

Just my observations
Sebastian

> The same files passed via Firefox work. I don't know whether it's  
> 100% success, though.
> 
> 
> >> I know very little about apache, bear with me.
> >> Currently I have this config:
> >
> > Hm, no, you either use mod_ngobjweb OR mod_proxy :-)
> >
> >
> > OK, back to the start ;-) What is mod_ngobjweb. Its
> > a) a non-streaming proxy
> > b) a protocol downgrader
> > c) a load balancer which works in combination with snsd
> > You usually don't care about c).
> >
> > a) means that mod_ngobjweb collects the whole HTTP requests sent by  > 
the browser before it transfers it to the SOPE application. This  
> > removes the browser<->WAN<->Server latency/slowness towards the  
> > app. Which is important because the SOPE app is non-threaded (and  
> > doesn't use non-blocking-IO for reading requests), hence it should  
> > not block on IO.
> >
> > b) is basically the reason why you could not use Apache mod_proxy  
> > as a SOPE frontend, even if you don't care about issue a). SOPE  
> > applications are not fully conforming HTTP servers, especially not  
> > HTTP/1.1 ones. Therefore Apache is used in front, which does all  
> > the HTTP heavy-lifting. mod_ngobjweb then talks HTTP/1.0 w/o  
> > keepalive etc to the SOPE app.
> > Now the new thing (and that was my comment in the last mail) is,  
> > that mod_proxy can now also do the downgrade for 'b0rked' HTTP  
> > backend servers.
> >
> > Why would you want to use mod_proxy. Well, it comes preinstalled  
> > with every Apache and its of course much more stable :-)
> > Not sure yet how to resolve a) though.
> 
> 
> Question is: would it work to use mod_proxy?
> 
> > Summary for you: you probably want to ignore all that and continue  
> > fixing your specific mod_ngobjweb problem :-)
> 
> 
> Hhm, well... Any clue on what's wrong with the module?
> 
> Here's the latest crash (this morning); module had the fixes I sent you.
> 
> Thread 0 Crashed:
> 0   libaprutil-1.0.dylib                0x00069218 apr_brigade_create  + 
42
> 1   httpd                               0x0002dcdd  
> ap_get_client_block + 98
> 2   mod_ngobjweb.so                     0x003b1a77 _readRequestBody +  269
> 3   mod_ngobjweb.so                     0x003b230c ngobjweb_handler +  502
> 4   httpd                               0x00002182 ap_run_handler + 70
> 5   httpd                               0x000028cf ap_invoke_handler  
> + 316
> 6   httpd                               0x0002a4e0 ap_process_request  + 
101
> 7   httpd                               0x00026eb6  
> ap_process_http_connection + 113
> 8   httpd                               0x00011055  
> ap_run_process_connection + 70
> 9   httpd                               0x0001146f  
> ap_process_connection + 81
> 10  httpd                               0x000308c6 child_main + 1169
> 11  httpd                               0x00030aae make_child + 384
> 12  httpd                               0x00030d11  
> perform_idle_server_maintenance + 480
> 13  httpd                               0x0003125d ap_mpm_run + 1285
> 14  httpd                               0x0000962b main + 2969
> 15  httpd                               0x000018f6 start + 54
> 
> 
> St=E9phane
> 
> 
> > Greets,
> >   Helge
> > -- 
> > Helge Hess
> > http://www.helgehess.eu/--
> > OpenGroupware.org Developer
> > developer@opengroupware.org
> > http://mail.opengroupware.org/mailman/listinfo/developer
> 
> -- 
> OpenGroupware.org Developer
> developer@opengroupware.org
> http://mail.opengroupware.org/mailman/listinfo/developer
> 


From developer@opengroupware.org  Thu Mar 27 13:58:14 2008
From: developer@opengroupware.org (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=)
Date: Thu, 27 Mar 2008 14:58:14 +0100
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: <D6F8C332-73DC-4411-A17E-DDCD97906A27@opengroupware.org>
References: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch> <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org> <C8AFCF45-05CB-46BE-BDC1-18499E49CCB3@sente.ch> <625BE739-2A5A-4D29-BCDE-5DBDE0FD78A4@opengroupware.org> <CBE2DBF5-1FE4-4025-BDC8-B5462CF46495@sente.ch> <D6F8C332-73DC-4411-A17E-DDCD97906A27@opengroupware.org>
Message-ID: <B0E33FED-B5E8-4ECF-A9BB-CDC1F484649F@sente.ch>

Hi,

On Mar 27, 2008, at 12:11 PM, Helge Hess wrote:

> On 27.03.2008, at 11:16, St=E9phane Corth=E9sy wrote:
>> I'm getting more and more confused :-(
>
> Sorry :-)
>
>>> Sure it does (and its used that way a lot in OGo, not exactly =20
>>> sure why you are experiencing issues).
>> OK, so that's good news.
>> Precisely, I used WOFileUpload, and mod_ngobjweb on apache 2.2.6/=20
>> OSX 10.5.2 Server.
>
> How did you get mod_ngobjweb to compile on 10.5.x? I didn't manage =20
> that :-/


Here's our mod_ngobjweb/GNUmakefile (we build mod_ngobjweb from =20
command-line, with a simple 'make'; building from Xcode doesn't work, =20=

for some reason):
http://www.sente.ch/pub/beta/mod_ngobjweb/GNUmakefile


> Maybe your problems are due to an 64bit issue? Might be possible =20
> that mod_ngobjweb has bugs here.


That could be, right, as Sebastian might have the same problems on a =20
x86_64.


>> Most of the time users can't upload files with Safari; repeating =20
>> the operation with the same file always fails: Safari sends file, =20
>> and waits forever.
>> I noticed the httpd crashed sometimes, in mod_ngobjweb code, or, =20
>> worse, becomes completely crazy and eats all memory and CPU!
>
> I've never seen that behaviour. Maybe Safari does HTTP pipelining =20
> or something like that, which in turn might confuse Apache/=20
> mod_ngobjweb. No idea, really.
>
>> Question is: would it work to use mod_proxy?
>
> Yes, it should work with mod_proxy. Its has the disadvantage that =20
> your app blocks on IO while the file is being uploaded. But maybe =20
> thats not a big problem for your app (certainly better than not-=20
> working-at-all ;-).


In our case it's not a problem to block the app during upload; I'm =20
gonna try the mod_proxy, thanks.


>> Hhm, well... Any clue on what's wrong with the module?
>>
>> Here's the latest crash (this morning); module had the fixes I =20
>> sent you.
>>
>> Thread 0 Crashed:
>> 0   libaprutil-1.0.dylib                0x00069218 =20
>> apr_brigade_create + 42
>> 1   httpd                               0x0002dcdd =20
>> ap_get_client_block + 98
>> 2   mod_ngobjweb.so                     0x003b1a77 =20
>> _readRequestBody + 269
>
> My best guess is 64bit issue or some 10.5.x incompatibility. Or =20
> some Apache 2.2 incompat. Don't know.
>
> Maybe you should just go for mod_proxy in this kind of setup (thats =20=

> what I use for 10.5 development too). Drop mod_ngobjweb from your =20
> Apache configuration, add mod_proxy and use the config section I =20
> showed in one of the previous mails.
>
> Greets,
>   Helge
>
> PS: the real solution would be to write a threaded/nio =20
> WOHttpAdaptor. Thats what WebObjects did too (request processing =20
> would be done multithreaded, but -dispatchRequest: would still be =20
> single threaded).


What about using Apple's adaptor? (and later, the monitor - rewritten =20=

in ObjC - as it is opensource now)


Thanks!

St=E9phane


> --=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 Mar 27 14:10:42 2008
From: developer@opengroupware.org (Helge Hess)
Date: Thu, 27 Mar 2008 15:10:42 +0100
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: <B0E33FED-B5E8-4ECF-A9BB-CDC1F484649F@sente.ch>
References: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch> <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org> <C8AFCF45-05CB-46BE-BDC1-18499E49CCB3@sente.ch> <625BE739-2A5A-4D29-BCDE-5DBDE0FD78A4@opengroupware.org> <CBE2DBF5-1FE4-4025-BDC8-B5462CF46495@sente.ch> <D6F8C332-73DC-4411-A17E-DDCD97906A27@opengroupware.org> <B0E33FED-B5E8-4ECF-A9BB-CDC1F484649F@sente.ch>
Message-ID: <E3ACC0EB-2822-4ACA-A289-058F4A23929C@opengroupware.org>

On 27.03.2008, at 14:58, St=E9phane Corth=E9sy wrote:
>> PS: the real solution would be to write a threaded/nio =20
>> WOHttpAdaptor. Thats what WebObjects did too (request processing =20
>> would be done multithreaded, but -dispatchRequest: would still be =20
>> single threaded).
> What about using Apple's adaptor? (and later, the monitor - =20
> rewritten in ObjC - as it is opensource now)


Sure, might be viable. Though this doesn't fix the primary issue of =20
not having a non-blocking way to accept HTTP requests / deliver HTTP =20
responses. We really need a threaded (or NIO) WOHttpAdaptor =20
implementation (actually on GNUstep this should be reasonably easy, =20
but we would need to have a separate implementation for OSX).

Greets,
   Helge
--=20
Helge Hess
http://www.helgehess.eu/=

From developer@opengroupware.org  Thu Mar 27 14:56:33 2008
From: developer@opengroupware.org (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=)
Date: Thu, 27 Mar 2008 15:56:33 +0100
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: <E3ACC0EB-2822-4ACA-A289-058F4A23929C@opengroupware.org>
References: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch> <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org> <C8AFCF45-05CB-46BE-BDC1-18499E49CCB3@sente.ch> <625BE739-2A5A-4D29-BCDE-5DBDE0FD78A4@opengroupware.org> <CBE2DBF5-1FE4-4025-BDC8-B5462CF46495@sente.ch> <D6F8C332-73DC-4411-A17E-DDCD97906A27@opengroupware.org> <B0E33FED-B5E8-4ECF-A9BB-CDC1F484649F@sente.ch> <E3ACC0EB-2822-4ACA-A289-058F4A23929C@opengroupware.org>
Message-ID: <2EBFDC26-187B-4F03-A1C7-42E08FA1460E@sente.ch>

In the meantime, I tried to use mod_proxy, but my config didn't work. =20=

I added the following to my virtual host:

     ProxyRequests     Off   # no forward proxy, only reverse
     ProxyPreserveHost On    # Apache 2.0.31 and later
     ProxyVia          block
     ProxyBadHeader StartBody
	<Location "/PPUREdit">
         ProxyPass        http://127.0.0.1:20000/PPUREdit
         ProxyPassReverse http://127.0.0.1:20000/PPUREdit
         SetEnv force-proxy-request-1.0 1
         SetEnv proxy-nokeepalive       1
	</Location>

I removed, in the virtual host section, the use of mod_ngobjweb
(mod_ngobjweb is still loaded - needed for other virtual hosts)

When I try to connect, I get a 404. Request is not passed further, =20
though connecting with telnet on localhost 20000 works.

Any idea?


About the mod_webobjects: could it work as-is, or do I need to make =20
modifications in SOPE?

St=E9phane

On Mar 27, 2008, at 3:10 PM, Helge Hess wrote:

> On 27.03.2008, at 14:58, St=E9phane Corth=E9sy wrote:
>>> PS: the real solution would be to write a threaded/nio =20
>>> WOHttpAdaptor. Thats what WebObjects did too (request processing =20
>>> would be done multithreaded, but -dispatchRequest: would still be =20=

>>> single threaded).
>> What about using Apple's adaptor? (and later, the monitor - =20
>> rewritten in ObjC - as it is opensource now)
>
>
> Sure, might be viable. Though this doesn't fix the primary issue of =20=

> not having a non-blocking way to accept HTTP requests / deliver =20
> HTTP responses. We really need a threaded (or NIO) WOHttpAdaptor =20
> implementation (actually on GNUstep this should be reasonably easy, =20=

> but we would need to have a separate implementation for OSX).
>
> Greets,
>   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 Mar 27 15:06:51 2008
From: developer@opengroupware.org (Helge Hess)
Date: Thu, 27 Mar 2008 16:06:51 +0100
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: <2EBFDC26-187B-4F03-A1C7-42E08FA1460E@sente.ch>
References: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch> <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org> <C8AFCF45-05CB-46BE-BDC1-18499E49CCB3@sente.ch> <625BE739-2A5A-4D29-BCDE-5DBDE0FD78A4@opengroupware.org> <CBE2DBF5-1FE4-4025-BDC8-B5462CF46495@sente.ch> <D6F8C332-73DC-4411-A17E-DDCD97906A27@opengroupware.org> <B0E33FED-B5E8-4ECF-A9BB-CDC1F484649F@sente.ch> <E3ACC0EB-2822-4ACA-A289-058F4A23929C@opengroupware.org> <2EBFDC26-187B-4F03-A1C7-42E08FA1460E@sente.ch>
Message-ID: <9196A856-1247-48C1-AB9A-877DC6909613@opengroupware.org>

On 27.03.2008, at 15:56, St=E9phane Corth=E9sy wrote:
> When I try to connect, I get a 404. Request is not passed further, =20
> though connecting with telnet on localhost 20000 works.


Your Location somehow doesn't match. If it would be a backend connect =20=

issue, you would get a 503 or something like that.
Check your Apache log files :-) Maybe increase the loglevel.

Greets,
   Helge
--=20
Helge Hess
http://www.helgehess.eu/=

From developer@opengroupware.org  Thu Mar 27 16:08:14 2008
From: developer@opengroupware.org (Wolfgang Sourdeau)
Date: Thu, 27 Mar 2008 12:08:14 -0400
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org>
References: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch> <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org>
Message-ID: <47EBC66E.3070701@inverse.ca>

This is a multi-part message in MIME format.
--------------090400040508000003050009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Helge Hess a écrit :
> On 26.03.2008, at 18:18, Stéphane Corthésy wrote:
>> I found bugs in mod_ngobjweb:
>>
>> In NGBufferedDescriptor.c, at the beginning of 
>> NGBufferedDescriptor_read(), availBytes is initialized by 
>> numberOfAvailableReadBufferBytes(self), whereas the test "if(self == 
>> NULL)" is done later; this could crash. BTW, 
>> numberOfAvailableReadBufferBytes(self) should be called only just 
>> before "if (availBytes >= _len)".
>>
>> In handler.c:
>> Around line 721, after NGBufferedDescriptor_safeRead(), you free 
>> 'toApp', but don't NULLify it, and some lines later the pointer is 
>> freed again when not NULL.
>> BTW, there is a "#if HEAVY_LOG" whereas everywhere else you use 
>> "if(HEAVY_LOG)".
There are still a few lines where setting toApp to NULL is required. 
Here is a patch that applies to your latest changes in handler.c.

Along with the NULLification, a cleanup has been made to avoid 
duplication of code. And the closing of the connection has been moved to 
the end of the function because it should happen unconditionnally to 
avoid leaking connections.

You may want to change my "if (var)" to your "if (var != NULL)", but the 
rest of the logic has been in production here for many months already 
without any problem.


Wolfgang




Index: sope-appserver/mod_ngobjweb/handler.c
===================================================================
--- sope-appserver/mod_ngobjweb/handler.c    (révision 1618)
+++ sope-appserver/mod_ngobjweb/handler.c    (copie de travail)
@@ -267,7 +267,7 @@
   const char           *uri;
   unsigned             requestContentLength;
   void                 *requestBody;
- 
+
   uri = r->uri;
   requestContentLength = 0;
   requestBody = NULL;
@@ -404,6 +404,9 @@
                  "could not create socket in domain %i.", domain);
     return DECLINED;
   }
+/*   else */
+/*     ap_log_error(__FILE__, __LINE__, APLOG_ERR, 0, r->server, */
+/*                  "appFd socket created in domain %i: %d", domain, 
appFd); */
 
   if ((result = _connectInstance(r, appFd, address, addressLen)) < 0)
     return 500;
@@ -646,7 +649,10 @@
 
  writeErrorHandler:
   if (writeError == 1) {
-    if (toApp) NGBufferedDescriptor_free(toApp);
+    if (toApp) {
+      NGBufferedDescriptor_free(toApp);
+      toApp = NULL;
+    }
    
     ap_log_error(__FILE__, __LINE__, APLOG_ERR, 0, r->server,
                  "socket write error during transfer of HTTP header 
section");
@@ -659,7 +665,10 @@
     if (!NGBufferedDescriptor_safeWrite(toApp,
                                         requestBody,
                                         requestContentLength)) {
-      if (toApp) NGBufferedDescriptor_free(toApp);
+      if (toApp) {
+    NGBufferedDescriptor_free(toApp);
+    toApp = NULL;
+      }
       ap_log_error(__FILE__, __LINE__, APLOG_ERR, 0, r->server,
                    "couldn't transfer HTTP req body to app server (%i 
bytes)",
                    contentLength);
@@ -677,7 +686,10 @@
   /* read response line */
  
   if (!NGScanResponseLine(toApp, NULL, &statusCode, NULL)) {
-    if (toApp) NGBufferedDescriptor_free(toApp);
+    if (toApp) {
+      NGBufferedDescriptor_free(toApp);
+      toApp = NULL;
+    }
     ap_log_error(__FILE__, __LINE__, APLOG_ERR, 0, r->server,
                  "error during reading of response line ..");
     return 500;
@@ -716,16 +728,8 @@
       }
 
       // read whole response
-      if (!NGBufferedDescriptor_safeRead(toApp, buffer, contentLength)) {
-        if (toApp) NGBufferedDescriptor_free(toApp);
-      }
+      NGBufferedDescriptor_safeRead(toApp, buffer, contentLength);
 
-      // close connection to app
-      if (toApp) {
-        NGBufferedDescriptor_free(toApp);
-        toApp = NULL;
-      }
-
       ap_log_error(__FILE__, __LINE__, APLOG_INFO, 0, r->server,
                    "send response (size=%i)",
                    contentLength);
@@ -739,15 +743,14 @@
       int result = 0;
       int writeCount = 0;
 
-      do {
-        result = NGBufferedDescriptor_read(toApp, buffer, sizeof(buffer));
-        if (result > 0) {
-          ap_rwrite(buffer, result, r);
-          ap_rflush(r);
-          writeCount += result;
-        }
+      while ((result = NGBufferedDescriptor_read(toApp,
+                         buffer,
+                         sizeof(buffer))
+          > 0)) {
+    ap_rwrite(buffer, result, r);
+    ap_rflush(r);
+    writeCount += result;
       }
-      while (result > 0);
 
       if (HEAVY_LOG && (writeCount > 0)) {
         ap_log_error(__FILE__, __LINE__, APLOG_INFO, 0, r->server,
@@ -756,10 +759,26 @@
       }
     }
   }
- 
+
+  // close connection to app
+  if (toApp) {
+    NGBufferedDescriptor_free(toApp);
+    toApp = NULL;
+  }
+
   return OK;
 }
 
+/* int ngobjweb_handler(request_rec *r) { */
+/*   int code; */
+
+/*   fprintf (stderr, "ngobjweb_handler...\n======================"); */
+/*   code = real_ngobjweb_handler(r); */
+/*   fprintf (stderr, "================ %d\n", code); */
+
+/*   return code; */
+/* } */
+
 #if WITH_LOGGING
 #if 0
 static void test(void) {


--------------090400040508000003050009
Content-Type: text/x-diff;
 name="mod_ngobjweb.fixes.diff"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="mod_ngobjweb.fixes.diff"

Index: handler.c
===================================================================
--- handler.c	(révision 1619)
+++ handler.c	(copie de travail)
@@ -646,7 +646,10 @@
 
  writeErrorHandler:
   if (writeError == 1) {
-    if (toApp) NGBufferedDescriptor_free(toApp);
+    if (toApp) {
+      NGBufferedDescriptor_free(toApp);
+      toApp = NULL;
+    }
     
     ap_log_error(__FILE__, __LINE__, APLOG_ERR, 0, r->server,
                  "socket write error during transfer of HTTP header section");
@@ -659,7 +662,10 @@
     if (!NGBufferedDescriptor_safeWrite(toApp,
                                         requestBody,
                                         requestContentLength)) {
-      if (toApp) NGBufferedDescriptor_free(toApp);
+      if (toApp) {
+	NGBufferedDescriptor_free(toApp);
+	toApp = NULL;
+      }
       ap_log_error(__FILE__, __LINE__, APLOG_ERR, 0, r->server,
                    "couldn't transfer HTTP req body to app server (%i bytes)",
                    contentLength);
@@ -677,7 +683,10 @@
   /* read response line */
   
   if (!NGScanResponseLine(toApp, NULL, &statusCode, NULL)) {
-    if (toApp) NGBufferedDescriptor_free(toApp);
+    if (toApp) {
+      NGBufferedDescriptor_free(toApp);
+      toApp = NULL;
+    }
     ap_log_error(__FILE__, __LINE__, APLOG_ERR, 0, r->server,
                  "error during reading of response line ..");
     return 500;
@@ -716,13 +725,8 @@
       }
 
       // read whole response
-      if (!NGBufferedDescriptor_safeRead(toApp, buffer, contentLength)) {
-        if (toApp != NULL) { NGBufferedDescriptor_free(toApp); toApp = NULL; }
-      }
+      NGBufferedDescriptor_safeRead(toApp, buffer, contentLength);
 
-      // close connection to app
-      if (toApp != NULL) { NGBufferedDescriptor_free(toApp); toApp = NULL; }
-      
       ap_log_error(__FILE__, __LINE__, APLOG_INFO, 0, r->server,
                    "send response (size=%i)",
                    contentLength);
@@ -736,15 +740,14 @@
       int result = 0;
       int writeCount = 0;
 
-      do {
-        result = NGBufferedDescriptor_read(toApp, buffer, sizeof(buffer));
-        if (result > 0) {
-          ap_rwrite(buffer, result, r);
-          ap_rflush(r);
-          writeCount += result;
-        }
+      while ((result = NGBufferedDescriptor_read(toApp,
+						 buffer,
+						 sizeof(buffer))
+	      > 0)) {
+	ap_rwrite(buffer, result, r);
+	ap_rflush(r);
+	writeCount += result;
       }
-      while (result > 0);
 
       if (HEAVY_LOG && (writeCount > 0)) {
         ap_log_error(__FILE__, __LINE__, APLOG_INFO, 0, r->server,
@@ -753,7 +756,13 @@
       }
     }
   }
-  
+
+  // close connection to app
+  if (toApp) {
+    NGBufferedDescriptor_free(toApp);
+    toApp = NULL;
+  }
+
   return OK;
 }
 

--------------090400040508000003050009--

From developer@opengroupware.org  Thu Mar 27 17:25:29 2008
From: developer@opengroupware.org (=?ISO-8859-1?Q?St=E9phane_Corth=E9sy?=)
Date: Thu, 27 Mar 2008 18:25:29 +0100
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: <9196A856-1247-48C1-AB9A-877DC6909613@opengroupware.org>
References: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch> <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org> <C8AFCF45-05CB-46BE-BDC1-18499E49CCB3@sente.ch> <625BE739-2A5A-4D29-BCDE-5DBDE0FD78A4@opengroupware.org> <CBE2DBF5-1FE4-4025-BDC8-B5462CF46495@sente.ch> <D6F8C332-73DC-4411-A17E-DDCD97906A27@opengroupware.org> <B0E33FED-B5E8-4ECF-A9BB-CDC1F484649F@sente.ch> <E3ACC0EB-2822-4ACA-A289-058F4A23929C@opengroupware.org> <2EBFDC26-187B-4F03-A1C7-42E08FA1460E@sente.ch> <9196A856-1247-48C1-AB9A-877DC6909613@opengroupware.org>
Message-ID: <03DFCFFF-43DF-498C-830E-0F1103D25567@sente.ch>

OK, I finally could do it. Using <Location> or <LocationMatch> didn't =20=

work, though it worked for the SetHandler directive. I needed to use =20
"ProxyPass /PPUREdit http://127.0.0.1:20000/PPUREdit" - same with =20
ProxyPassReverse.

Thanks for your help!

St=E9phane


On Mar 27, 2008, at 4:06 PM, Helge Hess wrote:

> On 27.03.2008, at 15:56, St=E9phane Corth=E9sy wrote:
>> When I try to connect, I get a 404. Request is not passed further, =20=

>> though connecting with telnet on localhost 20000 works.
>
>
> Your Location somehow doesn't match. If it would be a backend =20
> connect issue, you would get a 503 or something like that.
> Check your Apache log files :-) Maybe increase the loglevel.
>
> Greets,
>   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  Fri Mar 28 09:43:53 2008
From: developer@opengroupware.org (Helge Hess)
Date: Fri, 28 Mar 2008 10:43:53 +0100
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: <47EBC66E.3070701@inverse.ca>
References: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch> <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org> <47EBC66E.3070701@inverse.ca>
Message-ID: <0620CBC2-3E53-4119-AD7C-F936B571F3CE@opengroupware.org>

Hi,

whats the format of the patch?

helge@mbp$ patch -p0 <ngobjweb.patch
patching file sope-appserver/mod_ngobjweb/handler.c
patch: **** malformed patch at line 13: @@ -404,6 +404,9 @@

Thanks,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/

From developer@opengroupware.org  Fri Mar 28 13:13:56 2008
From: developer@opengroupware.org (Wolfgang Sourdeau)
Date: Fri, 28 Mar 2008 09:13:56 -0400
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: <0620CBC2-3E53-4119-AD7C-F936B571F3CE@opengroupware.org>
References: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch> <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org> <47EBC66E.3070701@inverse.ca> <0620CBC2-3E53-4119-AD7C-F936B571F3CE@opengroupware.org>
Message-ID: <47ECEF14.6070903@inverse.ca>

Helge Hess a écrit :
> Hi,
>
> whats the format of the patch?
>
> helge@mbp$ patch -p0 <ngobjweb.patch
> patching file sope-appserver/mod_ngobjweb/handler.c
> patch: **** malformed patch at line 13: @@ -404,6 +404,9 @@
>
> Thanks,
>   Helge
That is strange, I tested the patch from the email I sent and it 
(un-)applied perfectly.... Which version of the patch utility do you have?


W.




From developer@opengroupware.org  Fri Mar 28 13:20:59 2008
From: developer@opengroupware.org (Helge Hess)
Date: Fri, 28 Mar 2008 14:20:59 +0100
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: <47ECEF14.6070903@inverse.ca>
References: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch> <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org> <47EBC66E.3070701@inverse.ca> <0620CBC2-3E53-4119-AD7C-F936B571F3CE@opengroupware.org> <47ECEF14.6070903@inverse.ca>
Message-ID: <345D5D6F-7E74-4D27-9930-E7074B5C22DE@opengroupware.org>

On 28.03.2008, at 14:13, Wolfgang Sourdeau wrote:
> That is strange, I tested the patch from the email I sent and it  
> (un-)applied perfectly.... Which version of the patch utility do you  
> have?


---snip---
helge@mbp$ patch --version
patch 2.5.8
Copyright (C) 1988 Larry Wall
Copyright (C) 2002 Free Software Foundation, Inc.

This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.

written by Larry Wall and Paul Eggert
---snap---

There are multiple diff formats, I guess you generated a context-diff  
or something like that.

Helge
-- 
Helge Hess
http://www.helgehess.eu/

From developer@opengroupware.org  Fri Mar 28 13:28:04 2008
From: developer@opengroupware.org (Wolfgang Sourdeau)
Date: Fri, 28 Mar 2008 09:28:04 -0400
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: <345D5D6F-7E74-4D27-9930-E7074B5C22DE@opengroupware.org>
References: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch> <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org> <47EBC66E.3070701@inverse.ca> <0620CBC2-3E53-4119-AD7C-F936B571F3CE@opengroupware.org> <47ECEF14.6070903@inverse.ca> <345D5D6F-7E74-4D27-9930-E7074B5C22DE@opengroupware.org>
Message-ID: <47ECF264.2050904@inverse.ca>

This is a multi-part message in MIME format.
--------------020406050704050705060603
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


> There are multiple diff formats, I guess you generated a context-diff 
> or something like that.
>
> Helge
I have 2.5.9 (from Debian).... And the diff is a simple diff from svn. 
But I don't think it poses a problem.
Anyway here is one generated with diff -u...


Wolfgang




--------------020406050704050705060603
Content-Type: text/x-diff;
 name="mod_ngobjweb.fixes.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="mod_ngobjweb.fixes.diff"

--- handler.c.old	2008-03-28 09:27:00.000000000 -0400
+++ handler.c	2008-03-28 09:27:02.000000000 -0400
@@ -646,7 +646,10 @@
 
  writeErrorHandler:
   if (writeError == 1) {
-    if (toApp) NGBufferedDescriptor_free(toApp);
+    if (toApp) {
+      NGBufferedDescriptor_free(toApp);
+      toApp = NULL;
+    }
     
     ap_log_error(__FILE__, __LINE__, APLOG_ERR, 0, r->server,
                  "socket write error during transfer of HTTP header section");
@@ -659,7 +662,10 @@
     if (!NGBufferedDescriptor_safeWrite(toApp,
                                         requestBody,
                                         requestContentLength)) {
-      if (toApp) NGBufferedDescriptor_free(toApp);
+      if (toApp) {
+	NGBufferedDescriptor_free(toApp);
+	toApp = NULL;
+      }
       ap_log_error(__FILE__, __LINE__, APLOG_ERR, 0, r->server,
                    "couldn't transfer HTTP req body to app server (%i bytes)",
                    contentLength);
@@ -677,7 +683,10 @@
   /* read response line */
   
   if (!NGScanResponseLine(toApp, NULL, &statusCode, NULL)) {
-    if (toApp) NGBufferedDescriptor_free(toApp);
+    if (toApp) {
+      NGBufferedDescriptor_free(toApp);
+      toApp = NULL;
+    }
     ap_log_error(__FILE__, __LINE__, APLOG_ERR, 0, r->server,
                  "error during reading of response line ..");
     return 500;
@@ -716,13 +725,8 @@
       }
 
       // read whole response
-      if (!NGBufferedDescriptor_safeRead(toApp, buffer, contentLength)) {
-        if (toApp != NULL) { NGBufferedDescriptor_free(toApp); toApp = NULL; }
-      }
+      NGBufferedDescriptor_safeRead(toApp, buffer, contentLength);
 
-      // close connection to app
-      if (toApp != NULL) { NGBufferedDescriptor_free(toApp); toApp = NULL; }
-      
       ap_log_error(__FILE__, __LINE__, APLOG_INFO, 0, r->server,
                    "send response (size=%i)",
                    contentLength);
@@ -736,15 +740,14 @@
       int result = 0;
       int writeCount = 0;
 
-      do {
-        result = NGBufferedDescriptor_read(toApp, buffer, sizeof(buffer));
-        if (result > 0) {
-          ap_rwrite(buffer, result, r);
-          ap_rflush(r);
-          writeCount += result;
-        }
+      while ((result = NGBufferedDescriptor_read(toApp,
+						 buffer,
+						 sizeof(buffer))
+	      > 0)) {
+	ap_rwrite(buffer, result, r);
+	ap_rflush(r);
+	writeCount += result;
       }
-      while (result > 0);
 
       if (HEAVY_LOG && (writeCount > 0)) {
         ap_log_error(__FILE__, __LINE__, APLOG_INFO, 0, r->server,
@@ -753,7 +756,13 @@
       }
     }
   }
-  
+
+  // close connection to app
+  if (toApp) {
+    NGBufferedDescriptor_free(toApp);
+    toApp = NULL;
+  }
+
   return OK;
 }
 

--------------020406050704050705060603--

From developer@opengroupware.org  Fri Mar 28 13:29:44 2008
From: developer@opengroupware.org (Wolfgang Sourdeau)
Date: Fri, 28 Mar 2008 09:29:44 -0400
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: <345D5D6F-7E74-4D27-9930-E7074B5C22DE@opengroupware.org>
References: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch> <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org> <47EBC66E.3070701@inverse.ca> <0620CBC2-3E53-4119-AD7C-F936B571F3CE@opengroupware.org> <47ECEF14.6070903@inverse.ca> <345D5D6F-7E74-4D27-9930-E7074B5C22DE@opengroupware.org>
Message-ID: <47ECF2C8.6090705@inverse.ca>

> ---snip---
> helge@mbp$ patch --version
> patch 2.5.8
> Copyright (C) 1988 Larry Wall
> Copyright (C) 2002 Free Software Foundation, Inc.

Note that this looks quite outdated... 2.5.9 has been released in 2003. 
Is that from XCode 3 !??


W.


From developer@opengroupware.org  Fri Mar 28 13:44:50 2008
From: developer@opengroupware.org (Helge Hess)
Date: Fri, 28 Mar 2008 14:44:50 +0100
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: <47ECF2C8.6090705@inverse.ca>
References: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch> <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org> <47EBC66E.3070701@inverse.ca> <0620CBC2-3E53-4119-AD7C-F936B571F3CE@opengroupware.org> <47ECEF14.6070903@inverse.ca> <345D5D6F-7E74-4D27-9930-E7074B5C22DE@opengroupware.org> <47ECF2C8.6090705@inverse.ca>
Message-ID: <5251B764-F7AC-47F4-8BEF-21A9C4E46EF7@opengroupware.org>

On 28.03.2008, at 14:29, Wolfgang Sourdeau wrote:
>> ---snip---
>> helge@mbp$ patch --version
>> patch 2.5.8
>> Copyright (C) 1988 Larry Wall
>> Copyright (C) 2002 Free Software Foundation, Inc.
> Note that this looks quite outdated... 2.5.9 has been released in  
> 2003. Is that from XCode 3 !??


Yes, MacOSX 10.5.2 (I guess its included in the 10.5.2 itself, not the  
devtools). Anyways, the baseline patch format was always the same,  
AFAIK.

Helge
-- 
Helge Hess
http://www.helgehess.eu/

From developer@opengroupware.org  Fri Mar 28 16:28:33 2008
From: developer@opengroupware.org (Helge Hess)
Date: Fri, 28 Mar 2008 17:28:33 +0100
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: <47ECF264.2050904@inverse.ca>
References: <4FCA0B1D-9FBE-4DEF-9A16-6748AAC7C603@sente.ch> <F1F09863-E4F8-4197-A69D-2B267DF0E92C@opengroupware.org> <47EBC66E.3070701@inverse.ca> <0620CBC2-3E53-4119-AD7C-F936B571F3CE@opengroupware.org> <47ECEF14.6070903@inverse.ca> <345D5D6F-7E74-4D27-9930-E7074B5C22DE@opengroupware.org> <47ECF264.2050904@inverse.ca>
Message-ID: <9CCE8940-AFCD-43B1-BC60-E3F2E2918A4C@opengroupware.org>

On 28.03.2008, at 14:28, Wolfgang Sourdeau wrote:
> Anyway here is one generated with diff -u...


Gives me:
helge@mbp$ patch -p0 < wolf.patch
patching file handler.c
Hunk #1 FAILED at 646.
Hunk #2 FAILED at 662.
Hunk #3 FAILED at 683.
Hunk #4 FAILED at 725.
Hunk #5 FAILED at 740.
patch: **** malformed patch at line 90: }

Sorry.
(last error might be due to copy/paste, don't know).

Maybe I retry later on Linux.

Helge
-- 
Helge Hess
http://www.helgehess.eu/

From developer@opengroupware.org  Fri Mar 28 16:44:24 2008
From: developer@opengroupware.org (Wolfgang Sourdeau)
Date: Fri, 28 Mar 2008 12:44:24 -0400
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: 9CCE8940-AFCD-43B1-BC60-E3F2E2918A4C@opengroupware.org
Message-ID: <1d57-47ed2080-21-b7347570@181028246>

------=_=-_OpenGroupware_org_NGMime-7511-1206722664.649897-2------
content-type: text/plain; charset=utf-8
content-length: 545
content-transfer-encoding: quoted-printable

Here is a gzipped version... Maybe Apple Mail demacbinarize diffs and add a crypted resource fork ;)



-- 
Wolfgang Sourdeau
T: +1 514 989-2000 ext. 2602 C: +1 514 755-3520

AVIS - Ce courriel pourrait contenir des renseignements confidentiels ou privil=C3=A9gi=C3=A9s.
Si vous n'en =C3=AAtes pas le v=C3=A9ritable destinataire, veuillez nous aviser imm=C3=A9diatement.
Merci.
NOTICE - This e-mail may contain confidential or privileged information.
If you are not the intended recipient, please notify us immediately.
Thank you.

------=_=-_OpenGroupware_org_NGMime-7511-1206722664.649897-2------
content-type: application/x-gzip
content-transfer-encoding: base64
content-length: 1131
content-disposition: attachment; filename="mod_ngobjweb.fixes.diff.gz"

H4sICDby7EcCA21vZF9uZ29iandlYi5maXhlcy5kaWZmAM1W207bQBB9jr9iQII62E42NxxA
QVwaLmoUUEpb9cky9ppYtXbT9bqIov5717u2YwdDA+Kh+xB7LzM7c86ZcSzLgrlL/Aizltei
kd/oIjS0UM/qDgHt7XftfYRaKB9goT5CmmEYS6sai+4Ti6MjsHb7u6YNRvroIDg60kADuGch
x2PGKLtQDvfFIoQB6MsdGI2g04RHzYJsj9PjxaIJ0/OTJAgww/5HHHssXHDKnIBhnB040IwV
i0e1AuuaAsgpjGD6ZTLJFv9ockf9ugsnoncOTgPVHefscjJ2HBMcZ3I5lW/H15Orc2c8m5mA
TGDWYYzZL8xMZV4ZmzH1fmCuQAHpEvyEheQOOHNJLOIFGsDFzc01zLHri2mMPR5SsikClhgP
9iTGu90c4xyAjdqMYzfA39LbVNp1QT0zGP6Z4JifUP/h9VanlHBM+ASTOz5vFtS+hdxVehtr
2DVqSC1ofV9KBakeTSKffOBLDiWBAgq4FegJhYkbF6B8gL4Vwu0Dx3Fzs96fV8Euo922Je3D
3pL29o64wvXFT7ygJMYQhQTDTlvLpJuJ4rPnkll2ZCJOZEKQ0JiwHXOXJ/Ep9bFaav5/dfiu
FVgpuhS/9Clqropiq5UWXKZonjACA4QUFXZHtLceGHZ3YA6LCpTB5q/ttmLmfk4jXHgul8Dz
xToThjlFt/KIuaKIUjWVIIcNBZ3Y/TfmVbBF6Faew0usrReegC13J3DwIiowFSeI6mNZMTxp
B+8S/ivr+3J6drVWgceYlMpMj8PfeLQVvqZ+7Z4QzUCIpo/MTr+kmpDw1HMScZEOOigvy4/E
KU1IvpWn6dOyAgrrWthYDV9p/DTQ1bQpIqyoKfN3CKgiNIkqkzHpuSN1VDzLPtTBIEriub6y
UcrIGGXWpQOF+u7noagbXV87NdHx5chTLOYrqYp1dUOanfqavJyV2l8mYzTqcygysCoZlLA8
WLaHFOWL8fHX745QIWxvZ3+FlNM8sjKabxWzVN6gl3457IHsWpV2VTxk2JqRwv9CyRp1DX7N
9v6kuQuutWVzvfok4Ekb6F/IJJLUrwoAAA==
------=_=-_OpenGroupware_org_NGMime-7511-1206722664.649897-2--------

From developer@opengroupware.org  Fri Mar 28 19:04:54 2008
From: developer@opengroupware.org (Adam Tauno Williams)
Date: Fri, 28 Mar 2008 15:04:54 -0400
Subject: [OGo-Developer] JOPE now Go, on GoogleCode
In-Reply-To: <296687E6-50F2-4472-8422-A84C1735C825@opengroupware.org>
References: <296687E6-50F2-4472-8422-A84C1735C825@opengroupware.org>
Message-ID: <1206731094.4938.60.camel@WM_ADAM1.morrison.iserv.net>

> to check out the viability of GoogleCode, I have moved the JOPE  
> repository there. In the same run I renamed it to GETobjects, aka Go :-)

I assume this breaks the ChangeBlogger?

> (like in O..Go). If it works well, I will also checkin the OGoCore  
> Java stuff into GoogleCode. 

Cool

> Maybe even SOPE, OGo, SOGo as well. We'll see.
> All this should take some load from the OGo server machines and  
> improve reliability. We even get a Wiki ;-)



From developer@opengroupware.org  Sat Mar 29 00:38:17 2008
From: developer@opengroupware.org (Helge Hess)
Date: Sat, 29 Mar 2008 01:38:17 +0100
Subject: [OGo-Developer] JOPE now Go, on GoogleCode
In-Reply-To: <1206731094.4938.60.camel@WM_ADAM1.morrison.iserv.net>
References: <296687E6-50F2-4472-8422-A84C1735C825@opengroupware.org> <1206731094.4938.60.camel@WM_ADAM1.morrison.iserv.net>
Message-ID: <B451C108-BC70-4188-A425-428C83BD90E6@opengroupware.org>

On 28.03.2008, at 20:04, Adam Tauno Williams wrote:
>> to check out the viability of GoogleCode, I have moved the JOPE
>> repository there. In the same run I renamed it to GETobjects, aka  
>> Go :-)
> I assume this breaks the ChangeBlogger?

Not sure, not necessarily. I've added Svn externals, so if you  
checkout the 'old' JOPE repository, you actually get the results from  
GoogleCode.
Marcus probably can say, when he is back from Australia.

Greets,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/

From developer@opengroupware.org  Sat Mar 29 13:44:42 2008
From: developer@opengroupware.org (Helge Hess)
Date: Sat, 29 Mar 2008 14:44:42 +0100
Subject: [OGo-Developer] Bugs in mod_ngobjweb
In-Reply-To: <1d57-47ed2080-21-b7347570@181028246>
References: <1d57-47ed2080-21-b7347570@181028246>
Message-ID: <670D87BF-25AD-4961-B7CB-35D5AEDF828C@opengroupware.org>

On 28.03.2008, at 17:44, Wolfgang Sourdeau wrote:
> Here is a gzipped version... Maybe Apple Mail demacbinarize diffs  
> and add a crypted resource fork ;)


OK, this one worked. Its applied in r1620.

Thanks,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/