[jcifs] Re: SMB URL
conrad at apple.com
Fri Sep 14 08:00:13 EST 2001
At 1:43 PM -0700 9/13/01, Christopher R. Hertel wrote:
>> Every client and server might support either or both styles. And as new
>> software is installed every system can change in that regard. Probably
>> software will trend to supporting both styles, but that isn't certain. In
>> any case, our URLs should remain useful... if they are independant of
>> style. URLs specific to one style or another will soon be broken.
>I agree with all except the last sentance. As I said at the conference,
>and as part of this thread, the technical question (which must be
>answered) is this: Is there sufficient similarity between the protocol
>"styles" (I'd say transports) to warrant support for both in one URL
>You say yes, as does George. I need to get consensus from the community
>as a whole (and I am trying to present both sides, though it does take
>time to do so).
>As for the last sentance, allow me this example:
>- If someone was offering a file via FTP and then decided to serve the
> file via HTTP, the change would not invalidate the FTP "style" of file
> transfer. The original ftp:// URL string would also still be "valid";
> it's just that it would no longer point to anything. The string
> "ftp://ftp.apple.com/ms-windows/source/W2K/" is a syntactically valid
> URL string, it just doesn't point to anything (I hope).
>So, if we were to specify that SMB:// was SMB/NBT-only and that cifs://
>was CIFS/TCP only then someone changing a fileserver to run one 'style'
>rather than the other would not "break" the URL form. It would simply
>invalidate existing URL strings. That would, granted, be annoying to
Ah, I see. You read "broken" in a different sense than I intended. By
"broken" URLs I meant broken links, which amounts to a "minor annoyance",
or "frustrated customer hopelessly lost in cyberspace", or something in
between, depending upon degree of user sophistication.
To break the non-synonomous URL form, just add a new transport in 5 years
or so. With the synonomous URL form, the new transport slides on in.
Under a non-synonomous model a third prefix should be created. Yuck. If
one URL prefix can encompass the smantic and functional differences in smb
from windows xp back to early lanmanager, then I hope and expect it can
encompass this change too.
If we find we _must_ go down the path of N prefixes for this network
filesystem, then I'd like to see there be a special prefix which retains
ambiguity - one prefix which can be used when you want to create a link
which is likely to survive.
BTW ftp and http are so very different... I'd rather consider cifs/tcp vs
cifs tunneled over something - nfs lets say. The tunneled will have less
functionality, and perhaps subtle semantic issues, but for this would you
advocate breaking link-portability by having a different prefix?
Conrad Minshall ... conrad at apple.com ... 408 974-2749
Alternative email addresses: rad at acm.org and conrad at mac.com.
More information about the jcifs