libsmbclient: Browsing and a URI spec?

[Richard Sharpe]

At 11:25 AM 1/2/01 -0700, Matt Peterson wrote:
>"Christopher R. Hertel" wrote:

Much trimming has taken place ...

>> On a Windows box, you configure your default workgroup or domain along
>> with your machine name, etc.  It is part of the system configuration.  For
>> applications built on libsmbclient, it is really a user configuration.
>> Perhaps an individual user will want to consistently be within a given
>> workgroup, so the .smbc or .smb.conf file would be read to supply the
>> default.  How that is used is probably an application issue.
>> 
>> Could be wrong, though.
>> 
>> > Incidentally I'm sure it would be more than reasonable to want to enable
>> > Midnight Commander with smb functionality. I believe it is the foundation
>> > of the default GNOME file manager 'gmc' which IMO is right on the money
>> > as far as the type of applications we've been pondering.
>> 
>
>With regard to the specification of default workgroup, KDE offers
>utility classes (infrastructure) for saving configuration data -- as
>will many other applications.  Thinking out loud... it makes me wonder
>of libsmbclient should rely on a specific file like ~/.smbc.conf or if
>it would be better for developer (via the API) to set the default
>workgroup (on a per process basis).  I suppose that a default value
>could be read from .smbc.conf (if it exists) upon library initialization
>but offer the developer option of changing it.
>
>I do not think that libsmbclient should mimic windows behavior of making
>default workgroup a system parameter -- especially since it is expected
>that libsmbclient will be used on multi-user (Unix-like) platforms.  At
>the least, it should be a user configurable parameter...  The question I
>contemplate is whether default workgroup needs to be exposed via a
>standard text file at all.  Should it rather be a parameter (provided by
>the developer) to the library initialization API? 
>
>To a developer default workgroup is not much different than other
>"persistent preference" information like default username (and
>password), etc.  Developers should be free to store persistent
>information in ways that make sense to the application.  In KDE (and
>other file managers), the best way to do this will not be ~/.smbc.conf. 
>libsmbclient should allow developers maximum flexibility to provide very
>integrated applications for their users. libsmbclient should be a
>utility library for developers, not a solution for sysadmins or end
>users (i.e. users should not even know it is there).

While I agree that this is a (long-term) goal, it is going to be tricky!

I have made extensive use of Samba code that is riddled with accesses to
lp_xxx routines that pull values out of the smb.conf file.

The latest changes, which I have yet to commit, make use of a file in
$HOME/.smb/smb.conf and this works reasonably well.

To move in the requested direction, where each application has its own
resources will require a further modification to the smbc_init routine to
perhaps provide a callback that can retrieve parameters. However, I will
have to give serious thought to how this can be integrated into the current
code in such a way that we can continue to build it with Samba and against
the library.

>Neither users nor sysadmins should have to worry about yet another
>configuration file.  Developers *only* should be concerned with the
>details of how to persist preference information. 

Hmmm, adjective not like become verb, me thinks :-)

>-- 
>Matthew Peterson
>Sr. Software Engineer
>Caldera Systems, Inc
>mpeterson at caldera.com
>
>

Regards
-------
Richard Sharpe, sharpe at ns.aus.com
Samba (Team member, www.samba.org), Ethereal (Team member, www.zing.org)
Contributing author, SAMS Teach Yourself Samba in 24 Hours
Author, Special Edition, Using Samba