Directory listing in libsmbclient.so

[Steve Langasek]

Richard,

I think there's been a lot of good, healthy discussion about this question
today, but I fear we may be getting away from ourselves -- and from you, which
isn't good since you're the one actually writing this thing. :)  Getting back
to some of your comments...

On Thu, 28 Dec 2000, Richard Sharpe wrote:

> Firstly, the libsmbclient.so library alreay has a way for authentication
> information to be provided. There is a callback that is supplied when the
> smbc_init call is made.

> However, it is possible that an in-line method of specifying authentication
> may be needed as well.

I think it's very important that the 'userinfo' field of RFC 2396 be
supported.  Experienced users in particular (to speak modestly on their behalf
:), will want and expect this.

> Now, I have been thinking about all the feedback, and I wonder if forcing
> browsing of workgroups into the spec might be bending things too much out
> of shape?

> Perhaps I could simplify things by adding:

>   int smbc_set_workgroup(const char *wg)

>   char *smbc_start_wg_list(void)

>   char *smbc_next_wg(void)

> This would allow the workgroups to be listed; then we could go back to a
> kinder, gentler syntax for browsing within a workgroup.

I tend to agree with you that browsing shouldn't necessarily be crammed into
the same URI as smb filesharing access.  For one thing, browselists don't
*use* SMB. :)  Unless I'm mistaken, browse lists are assembled and displayed
to the client using only ports 137 and 138, and no SMB packets are ever sent.
So in this sense, I do think it's a bit silly to make these browse lists
available in an smb:// URL.  Consensus seems to be moving toward overloading
the <server> portion of the URL to represent the workgroup as needed, but I
think the ambiguities this introduces, and the complexity of the additional
code for resolving these ambiguities, are still a strong deterrent to this
approach.  We're still a long way from even reaching consensus about *how* the
ambiguity should be resolved.  Give precedence to a workgroup? Give precedence
to a server?  Let the application programmer sort it out?  Display both to the
user and let him decide?  All of these approaches have some merit, but I think
a URL which is unambiguous in the first place has more merit than any other
approach.

Does there need to be a way to textually access the browse list for a
workgroup?  Yes.  Does it need to be a url beginning with `smb://'?  I don't
think it does.  It would be nice if typing smb:// could take us straight to a
list of servers (or of workgroups? Another choice to be made :), but I don't
think this feature's important enough that we should tolerate ambiguous URLs.

Steve Langasek
postmodern programmer