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
project.


>  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.

Oleg

> 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


Mime
View raw message