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

List:       kfm-devel
Subject:    RE: internet keywords - great!
From:       Yves Arrouye <yves () realnames ! com>
Date:       1999-11-02 2:35:27
[Download RAW message or body]


> Anyway, as I was the person who implemented/hacked the so 
> called "short-URL"
> support into kfm and minicli, I am interested to know how you 
> deal with short
> URLs, for example "linuxtoday.com".  This is not exactly a 
> keyword, all it is
> missing is a scheme-part ( aka a protocol).  RFC 2396 
> appendix F mentions a
> little bit about this but does not encourage/discourage its 
> use.

linuxtoday.com would have to be a keyword for it to work. Today's Internet
Keyword APIs are simple (simplistic even I would say) but I expect that
there will soon be a way of querying for keywords, and taking decisions
based on its availability or not. Thus, an application (or the filter) could
see if the keyword exists and if not pass it to another filter. The chaining
of filter would then have to be right for that to work, but it may open up
nice ways of obtaining the behavior one wants.

> ?  This same thing is valid question for local executables.  
> If I, for example,
> just type kppp in the location bar while konqueror is showing 
> the contents
> of /opt/kde/bin directory, the word should not be resolved as 
> an internet-
> keyword.  It should rather cause kppp to be launched ( always 
> local resolution 
> first ...)

That works in my 1.1.2 patch but not in 2.0. I guess that's because URL
filtering is done before konqueror looks for local names. Oops. OTOH one can
say ./kppp. So maybe it's good to be able to say ./kppp to laucnh it but
Kppp to go to its homw page?

> The other thing I want to mention is that I think the internet keyword
> idea should probably go into a class like KURLFilter 
> (non-existant at the
> moment).  I will have to think more about this, but appreciate any
feedback ...

Definitely. Especially with user-oriented features, where it will be bad if
one application can do it and not another one. Filters should be
registerable, dynamically if possible. KURL already supports protocol
registration and should support that too, it's really useful. I actually
emailed Simon today to ask him about that, nice timing...

Yves.

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