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
>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
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.
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
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,
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
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
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
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
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
10 matches
Mail list logo