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

List:       kde-devel
Subject:    Re: URL filtering in kio_slaves [was Re: smb [was: Re: KWin Development]]
From:       Dawit A <adawit () earthlink ! net>
Date:       2000-03-31 15:14:38
[Download RAW message or body]

Hello,

On Fri, 31 Mar 2000, Nicolas Brodu wrote:
> > 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
> 
> Thanks for your explanations about KURIFilter.
> The thing is, kio_slaves are supposed to receive correct URLs (aren't they?). I
> can use KURIFilter in kio_smb to make the code even more robust, but I'm
> personally happy with assuming the check/completion has been made before.
> I could modify libsmb++ internal parser to use KURIFilter, but it would not be
> independant from KDE anymore. And again, is our case it would be useless since
> the library code should not have to deal with incorrect URLs.
> 
> So, the question is, do we want to check URLs in kio_slaves or not?ndex.html

Well I only said that becuase I thought that you wanted to garauntee such URLs
always got filtered.  But you are correct in that the filtering should be done
at the application level before it reaches the kio_slaves so that they do not
have to deal with any of it.  That is exactly what KURIFilter was designed for
since it is in kdelibs any app can use it at any time to support such invalid,
but commonly used protocols :))  The plugin design also allows new filters to
be added at a future date independent of any KURL modification.  So what I can
do for you is add all this filtering into the shortURI filter which will immediately take
care of konqueror and in the near future minicli.  Whenever other app
developers complaing about smb not recoginzing "smb:" or whatever, just tell
them to use KURIFilter.  Does this sound like a good solution ??  If so once I
finish the re-write of the KURIFilter code, I will remove your hack from KURL...

> If yes, it can still be done in kio_smb (not libsmb++) using KURIFilter.

Right.  Sorry for the confusion b/n the two :)

> > 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.
> 
> It's just a matter of recognising <scheme>://, independently of the protocol.
> We did not even agree here on the validity of <scheme>:// BTW.
> The application (kio_smb) does not rely on the hack itself, just on <scheme>://
> beeing valid.

According to RFC 2396 neither <scheme>:// nor <scheme>: are valid.  <scheme>:/
is okay becuase it represents non heirarchial path based URIs such as "file:/". 
So IMHO "smb:" or "smb://" have to be converted into "smb:///" or "smb:/"
depending on the fact that smb is a hierarcial protocol.  Thus, it is mostly
likely going to get converted into the former one ??

Regards,
Dawit A.

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