libsmbclient: Browsing and a URI spec?

[Matt Peterson]

"Christopher R. Hertel" wrote:
> 
> Mike,
> 
> > > On Mon, 1 Jan 2001, Christopher R. Hertel wrote:
> > > > config file.  If no such default were specified, then the starting point
> > > > would be smb://.
> > >
> > > However, one of the advantages of using URL-like syntax is that it allows
> > > integration of SMB file browsing into more general-purpose applications.
> > > Starting browsing operations at the default workgroup level isn't necessarily
> > > appropriate for something like midnight commander, even though it's
> > > reasonable to want to integrate SMB-awareness into such applications.
> > >
> > I don't understand. I would think it's ideal for something like Midnight
> > Commander. By default, users would probably want to browse the servers
> > of their workgroup, yes? Presumably this would be specified in your
> > .smbc?
> 
> 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.
> 
> The KDE file manager has partial smb support, provided by Nicolas Brodu
> using his own libsmb++.  Last I heard, however, Nicolas' situation had
> changed and he was no longer able to spend time to support the work.  This
> would be a good thing for someone on this list to pick up.
> 

Caldera sponsorship of libsmbclient is a direct result of a Caldera
project to rewrite the KDE kioslave that provides SMB support in
Konqueror.  Nicolas Brodu was involved in several discussions before the
libsmbclient project was started and agreed that libsmb++ functionality
belongs in an Samba owned library (libsmbclient).  The work on the KDE
kioslave for SMB is already started and continues in parallel with
Richard's work on libsmbclient.  

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

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. 

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