libsmbclient: Browsing and a URI spec?

[Welsh, Armand]

agreed.  I have pondered this for a little bit, and I think I like the idea
of a .smrc, or whatever file, that stores default settings.  Then other apps
can use it, or reject it.  If the file uses the simple format of
variable=value for each line, ignoring text after a # sign, then the file
could be used by scripts, by simply executin the file, having the effect of
setting environment variables, much like redhat systems do for the startup
scripts, and it could be read by the applications that choose to utilize
this information, or ignored completely, for brosers that choose to handle
it their own way.  The only exception, of course, is that the file should
not store passwords.  Just basic info, such as:

#~/.smbrc
# Default Configuration Parmeters for libsmbclient

# Domain to Authenticate Against
# - if set, authenticate against any (*) domain controller
DOMAIN=Gotham

# Default workgroup to browse
# - if not set, and domain is set, then WORKGROUP=DOMAIN
WORKGROUP=BatCave

# NetBios Name to use for Client Browsing
NBTNAME=Wayne_Manor

# Default user to Authenticate as
USER=Batman

# list of WINS servers, space (" ") delimited.
WINS=192.168.2.1 192.168.2.5


-> -----Original Message-----
-> From: Richard Sharpe [mailto:sharpe at ns.aus.com]
-> Sent: Wednesday, January 03, 2001 12:59 AM
-> To: Matt Peterson; Christopher R. Hertel
-> Cc: Samba Technical
-> Subject: Re: libsmbclient: Browsing and a URI spec?
-> 
-> 
-> 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



-> -----Original Message-----
-> From: Richard Sharpe [mailto:sharpe at ns.aus.com]
-> Sent: Wednesday, January 03, 2001 12:59 AM
-> To: Matt Peterson; Christopher R. Hertel
-> Cc: Samba Technical
-> Subject: Re: libsmbclient: Browsing and a URI spec?
-> 
-> 
-> 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