[jcifs] Re: Package access classes, methods, etc.

[Eric Glass]

> Actually I think the API access we have right now is quite good for
> several reasons. First, it helps facilitate the license agreement.
> Something like the SqlTransport you just posted is the kind of thing I
> would like to see people reciprocate. Second, it supresses "feature
> creep". If we keep the API "small" it will cause fewer problems for the
> casual user but non-casual users like yourself can still make
> sophisticated modifications. Consider the SqlTransport you submitted.
> Conceptually I think it breaks the API conventions we have followed so far
> because in theory it is just a named pipe transport and therefore should
> use the named pipe API. If the named pipe API is not sophisticated enough
> to support the target scenario we must determine why and make the
> necessary adjustments in a generic way.
> 

I would agree with the second point.  I'm not sure package access
really facilitates enforcement of the license, however; It's generally
possible to access the classes outside the package using reflection,
and putting an external class in a jcifs.* package doesn't imply
modification of jCIFS itself.  But I can see where you're coming from;
a couple of things that might be good (off the top of my head):

publicize constructor(s) for SmbException (so you can create an
SmbException externally).

publicize SmbSession.logoff().  I know this has come up before, but it
might actually increase scalability of the NTLM filter.  If the filter
did logon() immediately followed by logoff(), it could process a huge
number of concurrent users before hitting the maximum number of
sessions on the transport; you could possibly do logon()/logoff() in a
synchronized block and have a *single* session open on the connection
at any given time.  This would be an alternative to the ssnLimit
parameter (instead of letting sessions build up and creating new
transports, moderating the number of sessions).  Of course, I've never
tested any of this ;)


Eric