Whitespace and patches WAS Re: [Patch] SSM support for multicast.c

2005-01-11 Thread Colm MacCarthaigh
On Tue, Jan 11, 2005 at 06:25:57PM +, Julian Foad wrote: > Colm MacCarthaigh wrote: > >Patch also contains some whitespace/style cleanups my editor applied > >(uggh) [...] > > When you do a significant amount of whitespace cleanup, like in this patch, > it is better to send the cleanup and th

Start_tls failure detection

2005-01-11 Thread Brad Nicholes
>This is the app's problem though - if starttls fails it will return an >error, and it's normal on error to give up, which is the expected >behaviour. If the app chooses to ignore the error and go on with the >insecure connection, then it was the app's choice - it may have wanted >to do so. I think

Re: svn commit: r124824 - /apr/apr-util/trunk/ldap/apr_ldap_option.c

2005-01-11 Thread Brad Nicholes
So you will need to clarify one thing for me and we will probably have to both do a little more testing. The Novell docs state that ldapssl_init(,,0) is the same as ldap_init(). The only difference is that the potential connection has been prepared to become an SSL/TLS connection if desired.

Re: [PATCH] Trivial patch fixing up a few errorcodes.c strings

2005-01-11 Thread Julian Foad
Mihai Limbasan wrote: Attached is a minor patch fixing some error strings in misc/unix/errorcodes.c (missing periods, inconsistent language usage). Most of the strings did NOT end in a period. It would be more consistent to remove periods from those that do. The Subversion project extends the se

Re: [Patch] SSM support for multicast.c

2005-01-11 Thread Julian Foad
Colm MacCarthaigh wrote: Patch also contains some whitespace/style cleanups my editor applied (uggh) [...] When you do a significant amount of whitespace cleanup, like in this patch, it is better to send the cleanup and the functional change as two separate patches. (e.g. Load the original file,

Re: svn commit: r124243 - /apr/apr/trunk/random/unix/sha2.c

2005-01-11 Thread Julian Foad
William A. Rowe, Jr. wrote: Can I have a second set of eyes for a reality check before I backport this compile-time cleanup? It looks fine to me, if you think it is appropriate to back-port such a clean-up. The log message is rather difficult to understand. - Julian [...] Log: Clean up 4 extraniou

Re: svn commit: r124824 - /apr/apr-util/trunk/ldap/apr_ldap_option.c

2005-01-11 Thread Graham Leggett
Brad Nicholes wrote: As the code stands now with only the Novell SDK always calling ldapssl_init(), is this a problem? It is - suddenly you need to use APR differently if you are using Novell, as opposed to when you are using all the other toolkits which is what we're trying to avoid. If you a

Re: [INTRODUCE] apr-java

2005-01-11 Thread Mladen Turk
William A. Rowe, Jr. wrote: > Silly Question - doesn't this proposal fit better > in the commons project than Tomcat? > Perhaps, but the guys that are interested in both c and Java live inside J-T-C :). And since it will be buildable independent of any connector code, it could be moved to commons o

Re: [INTRODUCE] apr-java

2005-01-11 Thread William A. Rowe, Jr.
Silly Question - doesn't this proposal fit better in the commons project than Tomcat? For that matter, I'm rolling the dice that the apr project itself would entertain the possibilities of supporting jni / xs / c++ wrappers. The reason I suggest this is that we have .pkg and .rpm folks supporti

Re: svn commit: r124075 - /apr/apr/trunk/threadproc/unix/signals.c

2005-01-11 Thread jean-frederic clere
Bill Stoddard wrote: This is well outside my current knowledge, so take this comment for what's its worth (probably not much)... Would it make more sense to properly set SIGPROCMASK_SETS_THREAD_MASK depending on whether APR_HAS_THREADS or not? yes, but where to add: +++ #if APR_HAS_THREADS #def