hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ossf...@dubioso.net>
Subject Re: NTLMv2 in Apache HttpClient
Date Wed, 05 Mar 2008 19:50:46 GMT
Oleg Kalnichevski wrote:
> A _consistent_, _ASF wide policy_ on the use of LGPL licensed code 

The current policy is "talk to the legal guys" :-)

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


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

View raw message