[jcifs] Re: SMB URL encoding/decoding

[rjw]

Guys,

All of this talk about the url decoding, encoding got me to thinking. 
(This is practice now, not theory).

We're creating an AWFUL lot of String objects in Java that get tossed 
away. First, SmbFile takes an SmbURL String as a parameter. I've built 
up this SmbURL from all the little Strings I have lying around: 
username, password, server, path, etc. And the first thing that SmbFile 
does? breaks that SmbURL right back down into it's components.

Then, add in encoding. I do the following in my code:

   StringBuffer encodedPath = new StringBuffer();
   StringTokenizer st = new StringTokenizer (smburl, "/");
   while (st.hasToken()) {
     st.append (URLEncoder.encode (st.nextToken()));
   }
   smburl = encodedPath.toString();

That's a lot of String creates... would it be possible to add a second 
(third? another. =) constructor to SmbFile that takes the required 
components:

   public SmbFile (String server, String user, String pass,
                   String domain, String path);

Or whatever all of the required fields are (I'm not thinking entirely 
straight today.. too much bourbon last night). That would then allow you 
to directly assign them, Mike, instead of having to do all that parsing, 
thereby saving lots of cycles for object allocation and gc.

I'm not saying we should do away with the SmbURL constructor -- it's 
very handy -- but maybe we should support both.

/rjw
-- 
Robert J. Wygand, III, D.D.                  rob at wygand.com
GPG  [A267 C8F7 34C2 2896 20F3]  [7DC8 2605 9E4C 573A 20EC]

"They that can give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."