hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: NTLMv2 in Apache HttpClient
Date Wed, 05 Mar 2008 21:41:36 GMT

On Wed, 2008-03-05 at 20:50 +0100, Roland Weber wrote:
> Oleg Kalnichevski wrote:
> > 
> > A _consistent_, _ASF wide policy_ on the use of LGPL licensed code 
> The current policy is "talk to the legal guys" :-)

And ain't that lovely?

> >> Commons VFS has shipped with a jCIFS dependency, 
> > 
> > They no longer do. jCIFS module had to be moved to sandbox largely
> > because of the LGPL issue.
> I missed that when I recently visited their site.
> Thanks for the reminder.
> > Roland, you cannot expect a community to form around such a small code
> > base with such a narrow scope.
> A clean room (client) NTLM implementation (in Java) with native calls
> for Windows integration, that was the suggestion. We could use a Java
> NTLM implementation, Harmony could use it, MINA seems to be getting
> into protocols as well. jCIFS could use it too. To unit-test the code,
> it is basically necessary to implement the server side as well. That
> could make it interesting for Tomcat.
> Windows integration brings in a native element, so developers have to
> set up a C/C++ compiler anyway. At this point, it isn't a far jump to
> implement the (client) NTLM protocol in C as well, since both protocol
> and programming skills are there. Then add the non-Windows integrated
> authentication I mentioned in the previous mail, and you have an
> interesting proposal for commercial Linux distributions that want to
> sell their desktops into accounts with heterogeneous environments:
> Firefox automatically logging into an NTLM authentication proxy while
> running on a Linux platform.
> While we're at it, there might be some people interested in a Mono
> implementation. See logging.apache.org for an example of a project
> that solves a common problem across various programming languages.
> > Is there a community around HttpConn code?
> No. But HttpConn doesn't put additional requirements on development
> environments, OS platforms, or programming skills. Is there a community
> around HttpNIO? That was supposed to be just a few extra classes too,
> and it's now accounting for about half the traffic on our dev lists
> (perceived).

I guess that pretty much answers your question. As much as I consider
benefits of NIO greatly overrated, let's face the facts: interest in
HttpCore NIO has been driving most of the recent contributions to the

>  It does require additional programming skills, and it
> did add requirements to the development environment when we were still
> on Java 1.4 and you introduced HttpNIOSSL depending on Java 5. I surely
> stated my preference for a separate NIO component at the time.
> > We do not even know what code IBM is prepared to donate at this point,
> > if any at all.
> We do know that one of the two things that Cathy proposed is a platform
> specific feature. We have always denied requests for platform specific
> features. That native code is required is a guess of mine, but a likely one.
> Native code and/or Windows integration means a fundamentally different
> development environment from what we have now. If you feel we should
> change our views on that, you are welcome to start a discussion upfront.
> Until that discussion starts, I consider HC a project that is pure Java
> and cross-platform. And I will not mislead any potential contributors
> into believing that this is a good place to bring in platform specific
> features that are likely to require native code.
> > Your threats of vetoing contributions achieve nothing but
> > driving potential contributors away.
> Firstly, I'm not threatening anything. The Jakarta decisions page says:
> "Voters intending to veto an action item should make their opinions
>   known to the group immediately so that the problem can be remedied
>   as early as possible."
> I'm making my opinion known as early as possible. It is my understanding
> of a fair and open discussion to raise issues as soon as I identify them,
> in this case before anyone gets their hopes up high based on wrong
> assumptions. If somebody else had adverted Cathy that platform specific
> features are not exactly our business, or if you hadn't completely ignored
> the issue when replying to the mail in which I raised it, I wouldn't have
> had to emphasise it in this fashion.
> Secondly, I don't intend to veto contributions. I intend to veto
> significant changes to the way this project is running being brought
> in through the back door. Platform specific features and native code
> inevitably require such changes. Discuss them openly and upfront, or
> tell people that there is a misfit. That is surely better than letting
> somebody put work into contributions that will be rejected, and also
> better than forcing unwelcome changes upon us with the argument that
> "we can't reject this contribution now".

IBM needs this code written one way or another regardless of what we
think about it. The question is _what exactly_ they will be willing to
donate to the project. And it is still up to us to decide _what exactly_
and in which form we will be willing to accept. However, talking stuff
like vetoing contributions makes it less likely IBM will be willing to
donate anything at all.


> cheers,
>    Roland
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message