[jcifs] Re: SMB URL

[Conrad Minshall]

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
>format?
>
>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
>users.

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.