[jcifs] Problems with Wins Resolution
Michael B. Allen
miallen at eskimo.com
Sat Sep 28 05:17:15 EST 2002
On Fri, 27 Sep 2002 13:42:16 -0500
"Christopher R. Hertel" <crh at ubiqx.mn.org> wrote:
> On Thu, Sep 26, 2002 at 02:38:18AM -0400, Michael B. Allen wrote:
> > > ...unless there was a default workgroup. The default workgroup, by the
> > > way, is not part of the SMB URL. Samba and Windows have a default
> > > workgroup already, so this would just bring jCIFS up-to-speed in that
> > > sense.
> > Am I hearing you correctly? Wouldn't that really screw up the
> > semantics? If you get the servers who are members of your default
> > workgroup using just 'smb://' then how do you get the workgroup list?
> If that's what you're hearing then I'm doing a really lousy job of
> explaining. :)
> No, I'm really not suggesting mangling the semantics of the SMB URL. I'm
> saying that if the client software (jCIFS, whatever) has a default
> workgroup name then that name could be used by the client code to find the
> DMB and grab the workgroup list from that, just as would be done using an
> LMB. The default workgroup name is part of the application...nothing to
> do with the SMB URL.
> So, given the string "SMB://", the client might first look for the
> MSBROWSE name. If that is not found, then the client could look for
> <default_wg>#1D (likely futile since the MSBROWSE name wasn't found) and
> the <default_wg>#1B name (last ditch). If the <default_wg>#1B name is
> found (via the NBNS), then the client would query for the browse list, and
> present just the list of workgroups.
> Am I making any more sense? :)
Yes. Added it to docs/todo.txt.
A program should be written to model the concepts of the task it
performs rather than the physical world or a process because this
maximizes the potential for it to be applied to tasks that are
conceptually similar and more importantly to tasks that have not
yet been conceived.
More information about the jcifs