On 03/03/2008, Roland Weber <[EMAIL PROTECTED]> wrote: > Hi Oleg, > > > > Not that we are able to properly maintain the existing NTLM code either. > > A better and cleaner NTLM implementation would be still be a big step > > forward. > > > And I don't object to a better implementation that is cross-platform > and pure Java. If it comes with decent test coverage, I'll give it a +1. > But Cathy is asking for integrated Windows authentication, too. > > > > We have been waiting several years for an approval to depend on LGPL > > libraries. > > > Have we? When and where was it requested, and by whom? > We have been waiting, yes. But for what? That the Board suddenly > announces that it is now OK to ship code with LGPL dependencies? > It's not going to happen. LGPL dependencies are a case-by-case > decision, to be made by the responsible PMC in cooperation with > the VP of the legal committee (or whatever is the correct title). > That's Sam Ruby for now. > > Commons VFS has shipped with a jCIFS dependency, though they are > probably using it via smb:// URLs rather than through the API. > Recently, Trustin Lee of the MINA PMC has inquired about the > possibility to ship code that depends on LGPL by direct imports. > After an initial response of "no way",[1] there was a bit of a > discussion and that ended with a statement [2] which I interpret > as "it's ok, if...". The requirements from Apache policies are: > > a) the product must be useable without the LGPL dependency > b) the LGPL dependency must not be downloaded automatically > > a is a no-brainer, and b can be achieved by not having a pom.xml > in SVN and the source distribution. Call it lpgl-pom.xml and ask > folks to rename or set a link, then nobody can claim they were > not aware of the dependency.
Or declare it as a system dependency? > We have our own PMC now and are no longer subject to the Jakarta > policy on LPGL dependencies. Not sure I follow that; surely the Jakarta rules are derived from ASF rules? > If we _want_ to, I'm sure we can > work out a strategy for releasing LGPL-dependent code with the > legal committee in less than a month, just as Trustin did. But > I'm not going to start this kind of discussion until we have a > case to discuss. Nobody has time to work on a jCIFS bridge, so > I'll just let it rest and dangle along. +1 > > How long do you suggest we should wait? > > > Sam Ruby mentioned in [2] that he doesn't know whether he can > make it for the February board meeting. I guess he didn't, and > maybe he'll miss the March one as well. But he took over his > role only late last year and was overwhelmed by new work. > The board meeting minutes were late for months, but he finally > caught up with that. Recently, a legal Wiki was created - the > first major improvement on legal-discuss I have seen for a long > time. He'll get around to it, don't worry. Turning the (in)famous > "3rd party draft" into a policy is the #1 priority of the legal > committee. > > [1] > > http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/[EMAIL > PROTECTED] > [2] > > http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200801.mbox/[EMAIL > PROTECTED] > > > > >> If the idea is to create a self-sustaining subproject for NTLM, I'm > >> all for it. But that means Incubator, not a code donation to us. > > > > The purpose of incubation is to form a community around a code base. The > > scope of NTLM is too narrow to expect a self-sustaining community to > > form around it. So what is the point of incubating that piece code in > > the first place? > > > If it doesn't have a community that can support it, then we shouldn't > release it. Our Charter says "Java components". I intend to veto any > attempt to bring native code into this project without a reasonable > expectation of long-term support. If it's platform specific non-native > code, for example something that plugs into the SUN JDK Windows-only > classes to implement integrated Windows authentication, I might let it > pass into the unsupported contrib tree, but not into a release. +1 > And releases are most likely what Cathy needs. > > > >> A question that remains is whether it makes sense to duplicate > >> the efforts of the Samba team at Apache. > > > > The scope of jCIFS is _significantly_ broader than just NTLM stuff. > > NTLMv1 code in HttpClient 3.1 is just a _single_ class. Even if split > > that code into a number of smaller classes it would still be nowhere > > close to jCIFS. > > > Then add a JNI wrapper with Windows-specific code to provide > integrated authentication. Since we'd hate to be Windows only, > we would hope that somebody does the same for Macs, if that is > possible at all. IIRC Samba supports integrated authentication > for Linux via a PAM module that hashes the password so it can > later be used for the NTLM authentication. If that works for Linux, > maybe it can be made to work on BSD, Solaris/Sparc, Solaris/x86, > AIX, HP-UX,...? Still fundamentally less than jCIFS, but surely > more than we could hope to ever handle ourselves. > > No native code without developers that have the skill, interest, > and development environment to build and maintain that code. > No integrated Windows authentication without native code. > If it's a pure Java NTLM implementation with a suitable > plugin point where _sombody_else_ can fit in the native code, > fine with me. > But my first choice would still be that Cathy's people help the > jCIFS team to implement NTLMv2 there in a way that we can easily > plug it into HttpClient, while we work out the policy that > allows us to release a bridge component. +1 > cheers, > > Roland > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
