[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: konqueror SMB support problems
From:       Simon Hausmann <sh () caldera ! de>
Date:       2000-09-19 8:32:05
[Download RAW message or body]

On Mon, Sep 18, 2000 at 07:18:35PM +0100, David Faure wrote:
> On Mon, 18 Sep 2000, Jelmer Feenstra wrote :
> >On Mon, 11 Sep 2000, Simon Hausmann wrote:
> >> Hi,
> >>
> >> Given the current problems with the smb slave in the KDE CVS Repository
> >> I think it would be very realistic to get your new smb slave into the
> >> 2.0 release. I (and probably whole kfm-devel@kde.org ;-) would be
> >> _VERY_ interested it testing it (and including it if it works better
> >> than the current smb ) .
> >>
> >> Is there any way to test it? :-)
> >
> >I've contacted Alexandr Makaryk about it, he sent me the .tar containing the 
> >MWN library and the SMB slave. It all looks quite useful, however I really 
> >think the current smb implementation is the better one. The implementation 
> >done by Alexandr is actually just a wrapper around smbclient (tools from the 
> >samba package) and doesn't allow for files to be actually read / streamed 
> >from a windows share.
> >
> >This means that copies have to be made of every file you're trying to access 
> >, this is,  if you guys go for the Corel solution. Brodu's libsmb++ uses 
> >actual replacements for the standard open / read / close functions, which I 
> >think is the way to go. This enables applications like pictureviewers or 
> >audioplayers to read the file directly from the network, instead of copying 
> >it first and reading it from the local drive afterwards, which is SLOW.
> >
> >BUT, in order for the libsmb++ code to keep functional, it has to be updated 
> >frequently :( This is not an issue if the smb slave is implemented using a 
> >smbclient wrapper. As long as the smbclient's output / input doesn't change, 
> >konqueror's (*limited*) smb support will be working great for a long time.
> >
> >Your thoughts / comments ?
> 
> I totally agree with you. I didn't know that Corel's kio_smb is only a wrapper
> around smbclient. Well, actually I guessed so but I didn't realise the implications.
> The major implication is, as you say: no real network transparency :((((
> This sucks. One is not maintained but does what we want, the other is maintained
> but doesn't do what we want. Argl. ;-)

I agree aswell. Although one could probably take the smb portions of the mwn library
and put them together with that new smb slave (after discussing that with Corel first,
of course) , there would still be the drawback of the "external" netserv process.

Bye,
 Simon

[prev in list] [next in list] [prev in thread] [next in thread]