On Fri, Jul 08, 2016 at 01:23:55PM -0400, Jorge Arellano Cid wrote:
On Fri, Jul 08, 2016 at 05:22:48PM +0200, Johannes Hofmann wrote:
On Wed, Jul 06, 2016 at 10:28:04AM +0200, Johannes Hofmann wrote:
On Tue, Jul 05, 2016 at 04:53:45PM -0400, John Gaffney wrote:
First, a huge thanks to all the Dillo team for their efforts: I just switched from 3.0.5 to the current snapshot to try out the mbedtls changes, and I am wowed not only by this, but by all the improvements in rendering, etc. Great work!
A few suggestions, all very minor, that might be added to the back of the development queue:
In the current snapshot, the navigation bar has changed, and the URL field does not seem to be taking into account font_factor -- with the result that the window is smaller than the font height. You can test this by setting, e.g., font_factor=2.0 in your dillorc (most dramatically for a tiny panel with small icons). The issue seems to be with this factor not being taken into account when bh and lh are set in make_panel() in ui.cc.
As far as I can see, one can use the context menu to download individual images on a page, or use the panel to toggle image > > > > loading. But if one wants not to download images in general, but to download all the images for some one page (e.g., a weather forecast page), then one has to toggle downloading of images on and then off again. Maybe a command could be added to KeysCommand_t in keys.hh, bound by default to something like Ctrl-i in keys.cc, with a corresponding call to a_Html_load_images() in handle() in ui.cc?
To make the switch to the current snapshot, I had, sadly, to terminate an instance of 3.0.5 that had been running continuously for 90 days without any issues. But to get that much up time it was necessary to add a little code so that SIGUSR1 would call a_Dns_freeall() and a_Dns_init(), otherwise (unless I am missing something) Dillo will persist in using the cached lookup indefinitely and not detect when the IP address has changed. So maybe some sort of key binding could be added that would flush the cache when needed?
good point. However I'd like to avoid another key-binding and rather do the right thing automatically. I could think of a general DNS entry timeout of a couple of seconds. In many cases DNS responses are cached at OS-level too respecting lifetime values given by the server.
Firefox has an option to configure the DNS cache expiration (network.dnsCacheExpiration). Attached patch implements a similar feature for Dillo.
Thanks for the patch Johannes.
Under the current workload, I guess I'll look at it in a couple of days.
BTW, different use cases are very interesting. We usually asume our use case is generic. Dillo has thaught me several times that's not the case.
true
I for instance, really avoid flushing the DNS cache as it is one of the slowest parts of my web browsing experience. Sometimes the ISP DNS server takes more time to answer than the page to load!
I use another DNS but it's very noticeable, and the sites I usually browse seldom change their IPs (I've even thought of caching to disk, go figure! ;)
So I'd like to know what's the use case behind this need. There's surely something on it (e.g. some site may want to distribute workload between different servers by changing IP, etc).
Searching for "getaddrinfo ttl" gives some interesting information about the topic. The general opinion seems to be that DNS caching should be handled by e.g. nscd(8) as the TTL value is available there and responses can be cached over process restarts of individual apps. That also seems to be the reason why getaddrinfo() doesn't give access to the TTL value (to avoid that all sorts of applications implement their own DNS caching scheme). Nevertheless I think that for the special case of web browsers some DNS caching is helpful. And e.g. Firefox does that too. Having a configuration option for the DNS cache expiration time one can have everything from no caching at all to caching forever.
One thing I know DNS queries are abused for is for tracking users. On the old dialup days, the DNS was very quick to answer, so I suspect something fishy going on when it takes so much time here on broadband...
Cheers, Johannes