Christopher R. Hertel
crh at nts.umn.edu
Thu Sep 13 15:16:05 GMT 2001
> 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.
Well, I can see the distinction and why there was a miscommunication on
this point. I don't, however, imagine users (they're real people, after
all, not just "customers") being "hopelessly lost".
Forgetting the relative sizes of the gaps between the hidden-from-view
protocol types, I don't see users getting hopelessly lost when they have
to switch from ftp to http and back again. Both protocols allow file
access and a 'smart' browser could easily apply mailcap MIME rules to FTP
files, if desired. From the user's perspective, how much difference is
there? From the user's perspective, not much.
> 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.
OH NO! There is *NO* way to know what kind of new transport we are
talking about and *NO* way to know if it will slide right in. We already
*have* alternate transports. There is SMB over NetBEUI, SMB over IPX/SPX,
DECNet, Banyan, etc., etc. The list goes on.
Besides, it isn't the new transport that I'm talking about. That appears
to be a solvable problem. It's the rest of the suite. I personally do
*not* know how to retrieve the W2K equivalent of the browse list.
Part of the goal of the SMB URL is to allow users to navigate the entire
service hierarchy. Under NBT, that means:
List of available workgroups (smb://)
List of workgroup/NTDomain member servers (smb://workgroup/)
List of server shares (smb://server/)
List of files/directories under a given share (smb://server/share/)
If we can, with some degree of technical face-saving, come up with a way
to do this for both protocol suites then the argument that it is valid to
further overload the URL form to that additional degree will make sense.
I just need to know how to read the W2K service list to see if this is
> Under a non-synonomous model a third prefix should be created. Yuck. If
> one URL prefix can encompass the semantic and functional differences in smb
> from windows xp back to early lanmanager, then I hope and expect it can
> encompass this change too.
That will be a bridge to be crossed when it starts burning.
> 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.
If there are multiple prefixes, one per transport and supporting suite,
then the likely reason will be that we cannot resolve the ambiguities.
> BTW ftp and http are so very different...
Not at the user level.
> I'd rather consider cifs/tcp vs cifs tunneled over something - nfs lets say.
...but that's not the issue at hand. It doesn't make sense to consider
SMB over NFS. The URL form won't support that anyway. (You would use an
NFS URL string of some kind, I think.)
> 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?
Why/how would it break link-portability?
Christopher R. Hertel -)----- University of Minnesota
crh at nts.umn.edu Networking and Telecommunications Services
Ideals are like stars; you will not succeed in touching them
with your hands...you choose them as your guides, and following
them you will reach your destiny. --Carl Schultz
More information about the samba-technical