[jcifs] Plusses, again.

[Allen, Michael B (RSCH)]

> -----Original Message-----
> From:	Rob Wygand [SMTP:rob at wygand.com]
> Sent:	Wednesday, January 23, 2002 7:44 PM
> To:	Michael B Allen
> Cc:	jcifs at samba.org
> Subject:	Re: [jcifs] Plusses, again.
> 
> Mike,
> 
> Been doodling with this. I tried wrapping all of the name params of the 
> new SmbFile() calls in all the listFiles() methods of SmbFile in 
> URLEncoder.encode calls(). This properly returns the path everytime 
> fully encoded. That *really* sucks for display purposes, though, because 
> now every path is always encoded and needs to be decoded for display. 
> Usually, though, we're only displaying the last bit, so maybe that's not 
> as bad a soultion as I think.
> 
> What might be better, though, would be to keep the *internal* stuff 
> always encoded, so it works... but to either add a new getDecodedPath() 
> or just always return the path in decoded format. If you do that latter, 
> then you always need to re-encode, which is expensive.
> 
	I don't think we can do that. The '@' sign needs to be encoded before being parsed
	because of the following scenario:

	smb://rsch;miallen@nyc12/public/legal@home.doc

	In this case, jCIFS cannot possibly know if the users credentials and path are:

	user: rsch;miallen
	server: nyc12/public/legal at home.doc

	or

	user: rsch;miallen at nyc12/public/legal
	server: home.doc

	If you think about this, it's impossible to tell. It must be encoded. Besides, being a
	bonified URL modeled after the various RFC's and IETF Drafts, it will be expected that
	the URL be encodable. It will be necessary that you create your own convention on top
	of this if you wish to abstact these details from users of your product.

	Mike