libsmbclient: Browsing and a URI spec?
sharpe at ns.aus.com
Wed Jan 3 08:58:51 GMT 2001
At 06:42 PM 1/3/01 +1000, Richard Sharpe wrote:
>Matt Peterson <mpeterson at caldera.com> write ...
>>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
There is another aspect here that deserves mention:
It is hoped that many applications will make use of this library.
They should not all be forced to maintain duplicate copies of
essentially the same information.
>>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 :-)
>>Sr. Software Engineer
>>Caldera Systems, Inc
>>mpeterson at caldera.com
>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
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
More information about the samba-technical