[jcifs] We seem to have found a home in Android Apps.

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Thu Jan 5 09:00:09 MST 2012

Am 05.01.2012 09:05, schrieb Michael B Allen:
> On Tue, Jan 3, 2012 at 8:00 AM, Jim Hurne<hurne at vivisimo.com>  wrote:
>> On 01/02/2012 08:18 AM, Sebastian Sickelmann wrote:
>>> i love to see that you think some contributors to jcifs would be great.
>>> But it is not that easy to participate to jcifs as for many other
>>> open-source projects.
>> I agree with Sebastian. In particular, the lack of a true version control
>> system is holding the JCIFS project back.
>> I'm sure Mike would agree he cannot do everything. In fact, based on some of
>> his responses to questions posted to the mailing list over the past year,
>> it's increasingly clear Mike has less time to devote to JCIFS than he had in
>> the past. This is perfectly reasonable. After all, it is a lot to ask one
>> person to maintain a critical library like JCIFS. Hosting the JCIFS source
>> code in a public version control system like git would definitely make it
>> easier for others to pitch in and help out.
>> Beyond version control, JCIFS could really use a true issue management
>> system. Such a system would: (a) make it easier to track and prioritize
>> reported issues, and (b) reduce the number of redundant posts on the mailing
>> list because people tend to look at the issue management system first.  In
>> terms of priority, the need for a true version control system is much higher
>> than the need for an issue management system, so I'd suggest looking into
>> git and samba.org git hosting first.
> Hi Jim,
> I have to totally disagree with you here.
> It's actually not that common to get a contribution that is accepted
> as-is. In fact with the exception of the NTLMSSP code from Eric and
> occasional one liners, I don't recall ever actually applying a
> contributed patch directly. In fact, contributed code is almost always
> wrong in some way (the NTLMSSP code is - I just rewrote for a
> commercial package to workaround problems where that code was not
> compatible with Windows behavior). I just look at what the contributed
> code does and then make the changes necessary to do what it fixes /
> does.
Hi Alan,

I totally agree. Patches that comes along must be reworked in
almost every case. However, i prefer a way of doing this with the
author of the patch. Giving the contributors feedback of what
is wrong with it patch and asking if the contributors wants to fix
it themself before submitting the patch again.
If the contributor had no time/knowlegde to rework the patch
then the maintainer can decide, base on how good the improvement is,
what to do with it and maybe rework it.
If i get you right you actually prefer the second step before the first.
It's ok. But i think introducing a short discussion step before doing
it on our own, can help to get more people to the level needed to
provide good contributions on there own.
>   Version control is of no use when you only have one person
> controlling the tree. JCIFS uses the Linux style development model -
> just take a copy, make the changes and post the new package. If the
> changes are useful, they will make it into the main tree.
Linux is using git. And there is a single maintainer of it. And it really
works fine. And it works fine because every developer that wants to dig
into the source and the source history can just do it. And they can
keep in sync with the mainstream maintained by Linus with very little
cost (pull,merge or rebase, ready).
JCIFS don't need the distributed features of git. But a public readable
repository would make a big difference.
However a distributed VCS like mercurial or git makes a big difference
for patch maintenance and it has almost no more cost compared
to a centralized one, but a centralized would make a big difference too.
>   If you want
> to post something in github, do it.
Nobody mentioned github here. Nobody(at least i hope so) wants to
create a fork or do anything like providing a public mirror on github
,that just mirrors the development of jcifs, without the agreement of
the community and the maintainer. We (the community) need your
experience that make jcifs just work for such a long time.
> In fact, I would go so far as to say that the current dev model is not
> holding the project back - it is holding it UP. If other people could
> commit to the tree I think it would turn into a mess.
Nobody want's commit permissions. Maybe in the future it would be great
to have a few "main-developers" that are able to check patches/bug reports
and do the discussion with the patch-contributors and rework the patches.
They can send in the reworked patches to the maintainer(in git this would
be something like a "pull request"). This is totally easy with a DVCS 
and this
is excatly how the Linux Kernel Developers do it and it is the reason why
git was build by Linus.
Linus is the maintainer of Linux. He pulls in changes from developers he 
I don't think jcifs needs this in the same dimensions as Linux needs it. 
in the small it works with almost no extra cost. Just use a DVCS and provide
a readable public repository.
>   This is in part
> because JCIFS is not very object oriented. There's a lot of encoding
> and decoding and multiplexing of messages and locking going on that
> has absolutely nothing to do with OOP. Most Java programmers are way
> over psyched about OOP and I would be very concerned that if someone
> were to be let loose on the JCIFS codebase they would quickly drive it
> into the ground. Try one of the crawler examples against a server with
> lots of files (like millions) in a memory profiler and look at the
> objects created. It creates almost NO objects (aside from lots of
> Strings because the String class is immutable and there's no string
> primitive). JCIFS is very lean as Java code goes. That was not an
> accident.
>>> Am 01.01.2012 22:54, schrieb Christopher R. Hertel:
>>>> Speaking of cellphones...
>>>> I know of two very popular file browser apps for Android that use jCIFS
>>>> as
>>>> their underlying SMB/CIFS implementation.  As far as I can tell, however,
>>>> there is no acknowledgement of jCIFS in these apps, and no pointer to the
>>>> jCIFS source.  I would like to see jCIFS acknowledged and the links
>>>> provided, per the license.  The LGPL was specifically chosen to make it
>>>> easy
>>>> to use jCIFS with closed-source applications, so there is no reason not
>>>> to
>>>> meet the terms.
> Actually this has come up on the list before about Android apps and
> the LGPL and I'm pretty sure I've told them to outright ignore the
> link-back requirement in the LGPL in this case and that if someone had
> a problem with that I would just re-license JCIFS using a new license
> that didn't have the link-back requirement. And I stand by that
> position. Sebastian may have been one of these people. I don't recall.
But maybe those who contributed to jcifs care about this licensing
> If someone has a link to said post be a sweet heart and reply to this
> message with the link for completeness please.
> The problem with the LGPL and "apps" is that the LGPL requires that
> the distributor either provide the source code with their package or a
> link-back to the source but at the origin of the binary (in this case
> the app store) and in a form that can be used to rebuild the
> distributors package with the possibly modified JCIFS source. For a
> variety of reasons this is not practical with any kind of "app store"
> for Android or Apple or whatever the next device OS is.
> However, I believe I did tell people to include the LGPL 2.1 license
> text and reference to JCIFS in their legalese that goes with the app
> and do everything except the link-back part. So in that respect, the
> distributor should credit JCIFS. If they don't do this, that is
> naughty. But unless they do something really interesting and we ask
> about it and they decline to provide the source, I just don't care
> honestly. JCIFS is not a new fresh innovative thing. It just
> implements and old boring network protocol (albeit an important one).
> The point being, it is highly unlikely that someone is going to come
> up with a derived work that does something really new and clever. Even
> if someone did a really good Kerberos mod, the Kerberos that comes
> with Oracle's Java is so bad, I'm not sure I would be all that excited
> about it.
> And from the questions being asked on the list it sounds like these
> Android apps are trying to do things like browse for servers on the
> network or print which probably makes for a pretty horrible app since
> NetBIOS is all but dead and printing is an ultra complex quagmire. So
> I'm not sure I want to be given credited for stuff like that :->
> Mike
If you like i can create a preview how such a git repository can look
like. If you like a can also maintain a public mirror of jcifs on
github or the samba-git-website based on the jcifs source-tar-balls.

Is there an archive of all the old source-tar-balls?
On http://jcifs.samba.org/src/ i only found a few. :-(

-- Sebastian

More information about the jCIFS mailing list