libsmbclient: Browsing and a URI spec?

[Richard Sharpe]

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
>the library.

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 :-)
>
>>-- 
>>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
>
>
>
>

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