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

List:       kde-devel
Subject:    Re: smb [was: Re: KWin Development]
From:       Dawit A <adawit () earthlink ! net>
Date:       2000-03-31 3:21:36
[Download RAW message or body]

On Thu, 30 Mar 2000, Nicolas Brodu wrote:
> This isn't that at all. It's just that internally the libsmb++ uses URLs for
> handling file locations. It should never receive 'smb:' from KURL as it isn't
> valid. What I mean is that if the lib receive one day smb:, it will still work
> (before, it asked a password for IPC$, which was clearly wrong). Once the
> parsing is done, the URL is rebuilt properly for internal management.
> As you see, this has nothing to do with KURIFilter. I just made sure the lib can
> handle internally whatever garbage is sent to it.

I basically understand what you are saying, but why isn't kio_smb, which is
the party that wants to properly deal with the invalid URL handle this ?? 
Might you be mis-understanding the purpose of KURIFilter ?  The basic purpose
of the KURIFilter class is to complete any URI's that can be commonly used but
are not valid such as the so called "shortURIs" such as "linux.org". 
KURIFilter only filters URI that are invalid to begin with so you do not have
to worry about it mangling the the valid ones.  Why wouldn't this work for the
"smb:" if you apply it from within libsmb++ ??  In fact, you can always go
through the filters first since they will reject URLs that are valid...

My problem with the your hack is that KURL is supposed to be a generic parser. 
If we keep on adding specific hacks into it, it would be difficult to keep it
upto date with the standards.  Moreover, if it happens to be re-written some
time down the line ( which I am planning to BTW ), your application might
break, because your specific hack might not be part of the new parsing code. 
This is why I do not like it.  To me It seems to be an application specific hack
put into a library class.   This way your code is not impacted no matter what
happens to KURL ( less dependency on proper format ... )

> > Is this why you added that static method to KURL ??  IMHO, that is wrong! I
> > personally think KURL is getting too big for its own good.  It is supposed to
> > only parse and at most validate URLs.  The filtering should be done by the
> > filter classes.  If you want I will add the filtering rule to shortURI filter
> > for converting "smb:" to the proper format...
> 
> The static function was a hack. It was not intended to convert smb: to smb:// or
> whatever, but just enable smb:// to be recognised as valid. Adding an entry in
> the .desktop file to say this protocol accepts empty host/path would get rid of
> this static.

Sorry, I did not completely see what the code was doing, it was a simple glance.

> I don't know about filtering, except that I didn't implement any of that in
> KURL. The only filter rule I set up was converting Samba notation \\host\path
> to smb://host/path when it's entered in konqueror location box, in
> konq_mainview.cc.

This is also going to change a bit.  The code in konqFilteredURL is duplicate
and no longer necessary since it is already handled by a plugin.  It is just
that nobody removed/changed it yet.  I will add your smb filtering code into
the "shortURI" filter.  This way any application and not just konqy ( minicli
for example [ in the near future ] ) can make use of it...

Regards,
Dawit A.

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