Short hostnames in URLs

Dawit A. adawit at
Fri Aug 9 06:52:52 BST 2002

On Thursday 08 August 2002 04:38, Lubos Lunak wrote:
> Dne čt 8. srpen 2002 03:43 Dawit A. napsal(a):
> > On Wednesday 07 August 2002 12:45, Lubos Lunak wrote:


>  So instead of adding it to kshorturifilter, I should write a new plugin
> for kdeaddons?  How does that change anything, besides being more work, and
> explicitly saying it's mine code and not yours? Nothing will change for the
> user.

First of all kdeaddons is just a suggestion, but you can add it wherever you 
please. Second where did I say it is mine and not yours ?  I've never said 
that. However, last I checked I, just like you, have every right to either 
object or agree with any patch anyone posts. Moreover, I've given you the 
technical reason for which I object to this patch, but you flat out choose to 
dismiss them. You refuse to see that the work your patch does is something 
that needs to be handled at a lower level not in the filter plugin which was 
not designed for this purpose.  That is the very reason why a similar 
suggestion were rejected the last time this issue came up, but I digress.  

Anyways, no matter how small the delay, you still end up doing multiple 
lookups on ALL one-word short url's like "localhost".  I 've several machines 
in the office that have easy to remember on word "short names" like admin.   
They are within one hop from where my computer is so why would I want to
go through the nameserver 2x rather than using a single rule like 
^admin=http://.  I understand how that can become unmaintainable for very very 
very large installations, but I do not really see it a problem for normal day 
to day usage compared to the alternative proposed. 

>  And I still fail to see the problem with having the lookup there. The DNS
> lookup is limited to 0,5s , which is nothing considering that right now the
> filter turns it into Google search, so the user would have to wait anyway.
> Morever, the DNS lookup is done only rarely, only if the command doesn't
> contain whitespaces, dots, colons, it's not a valid URL nor a valid
> command, which basically rules out almost everything except for things that
> would end up as a Google search anyway. Let me stress this once again:
> Unless I missed something, the lookup will be done only if it would
> otherwise become a Google search (but not for all Google searches).

If it only affects people that know how to use "shortnames", mainly power 
users, and even then only affects them under a very small subset of 
conditions, what would be advantage of this patch ?  See, this can be argued 
both ways using the same argument :)  

>  If you're still against applying this patch to kshorturifilter, I'll do as
> you said and put a new filter in kdeaddons, but given the things above, I
> consider it rather silly.

Well I do not consider this being silly and no I have not changed my mind.  I 
guess we will not see eye-to-eye on this issue. However, others might agree 
with your approach and if enough people do, then the patch should be applied.  
I neither want nor have a dictatorship power on such things... 

Dawit A.

More information about the kde-core-devel mailing list