[jcifs] jCIFS housecleaning questions

[Michael B Allen]

On Tue, 8 Jul 2003 eglass1 at comcast.net wrote:

> Mike,
> 
> I went through and did a general code cleanup on most of my stuff; I had a 
> couple of questions before putting the finishing touches on, though:
> 
> 1) In NtlmHttpFilter, we cache the name of the domain controller, and then do:
> 
>     UniAddress.getByName(domainController, true);
> 
> to get the UniAddress in each call to doFilter.  In NtlmServlet, however, we 
> have it doing the lookup in the initializer and storing the UniAddress object 
> for future use.  I'm not sure if UniAddress does its own name caching, so the 
> latter may or may not be more efficient.  Which approach should I adopt?

InetAddress has an address cache. jcifs.netbios.NbtAddress has an
almost identical address cache. UniAddress just calls InetAddress or
NbtAddress. So yes, there is caching. The second lookup should not go
out on the write. See jcifs.netbios.cachePolicy.

> 2) I wasn't able to locate the ServerMessageBlock.writeTime function mentioned 
> previously; there is a writeTime method, but it appears to be the complement of 
> readUTime (using a 32-bit value).  There is a readTime that *reads* the 64-bit 
> time value I am looking to write, but I couldn't locate a corresponding writer 
> function.  As a reference, I'm currently implementing this as:
> 
>     static void writeTime(long time, byte[] dest, int offset) {
>         time += 11644473600000l; // milliseconds from January 1, 1601 -> epoch.
>         time *= 10000; // tenths of a microsecond.
>         for (int i = 0; i < 8; i++, time >>>= 8) dest[offset + i] = (byte) time;
>     }
> 
> But the daylight savings adjustments made in the other *Time methods would 
> probably be appropriate.

If the encoded time is visible to the client in any way I would prefer
you not do half-now-half-later. I'll look at creating a proper writeTime
method that considers TZ. The question is, does your code _need_ the
TZ adjustment? If not then we can parameterize the adjustment with a
boolean flag. In the next big iteration I suppose we should break out
all of the trivial encoding/decoding methods into an "Encdec" class.

> 3) I *think* the only usage of Base64 is in the HTTP stuff; if so, I was going 
> to suggest the possibility of using the attached implementation.  It's quite a 
> bit cleaner, and about 2.5X faster.  This isn't as general-purpose as our 
> current implementation, however (it doesn't implement linewrapping, but neither 
> does HTTP).

Sounds great. Swap it in!

Mike

-- 
A  program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes  the  potential  for it to be applied to tasks that are
conceptually  similar and, more important, to tasks that have not
yet been conceived.