Short hostnames in URLs

[Lubos Lunak]

Dne pá 9. srpen 2002 07:52 Dawit A. napsal(a):
> 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:
>
> [snipped]
>
> >  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.

 I was just trying to say that I don't undestand why it should be moved into 
its own plugin when there would be no difference besides it being in its own 
plugin.

> 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.

 Ok, you understand this stuff better than I do, so where you suggest this 
'lower level' to be? If you find a better place for it, I'll change the code.

>
> Anyways, no matter how small the delay, you still end up doing multiple
> lookups on ALL one-word short url's like "localhost".

 I can cache the last hostname, that should take care of repeated filtering, 
if there's any done.

>  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.

 You would rather want to go through the nameserver because:
- you don't know how to add the rule (I don't think this is a power-user 
feature)
- you don't want to add many rules
- you simply don't want to bother adding anything (I guess you must have used 
another WWW browser in a large LAN to understand this)

>
> >  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 :)

 Based on this argument, I suggest removing Control Center from KDE, or at 
least half of its modules. And I'll be happy to follow this argument in KWin 
too :).

 I know a couple of people who consider the lack of this feature as strange 
and annoying as e.g. missing close button in window frames.

>
> >  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...

 Unless you know a better place where to put the lookup, I've attached 
(hopefully final and everybody sufficiently pleasing) another version. The 
lookup is done in an extra URIFilter, and minicli uses this filter only for 
the final filtering of the entered command (who cares the icon for local 
hostnames will be wrong). This makes thing feature work fine in Konqy or 
wherever else where it doesn't cause any serious problem, and not using it in 
minicli while typing avoids any possible delays. I've also increased the 
timeout to 1s.

-- 
 Lubos Lunak
 llunak at suse.cz ; l.lunak at kde.org
 http://dforce.sh.cvut.cz/~seli
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicli.patch
Type: text/x-diff
Size: 1494 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20020809/30ab3244/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plugins.patch
Type: text/x-diff
Size: 9098 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20020809/30ab3244/attachment-0001.patch>