On Wednesday 17 June 2009 20:19:25 sashee wrote: > Ok, I'll schedule that then. > > One thing that *is* critical is that we stop loading the images if the user > > closes the page, but afaics the existing infrastructure will do that. > > I really dont think that anything gets notified when the user closes > the tab. So I dont think fetching is stopped then. > > As I see the prefetching has a 1 minute timeout, so it isn't really > solving things. Inline prefetch fetches stuff, but only those, that > are fast, and kills the others. And the browser's request fetches the > other(almost all) images, 2(3) at a time. Asyncronous fetching would > solve that problem, because it can notify(and cancel) the fetches when > the user actually closes the tab.
Or at least within 21 seconds of closing the tab. :) Can you improve on that? > > sashee > > On Wed, Jun 17, 2009 at 8:28 PM, Matthew > Toseland<toad at amphibian.dyndns.org> wrote: > > On Wednesday 17 June 2009 19:23:22 sashee wrote: > >> So my question is: Is it needed? If it helps, I'll do it before the > >> midterm evals, but if it doesnt improve anything, then no need to > >> program it. > > > > Yes. IMHO it is important. Prefetching has never worked well on new nodes, > > and doesn't solve the connection limit problem anyway. Also the > > infrastructure will be interesting as later on we may want notifications on > > loaded pages (e.g. "there is a more recent version of this page available", > > but maybe also critical node events). > > > > Feel free to make a very basic implementation where you either have the > > loaded image or you have a loading graphic with no indication of how far it > > has got. *Ideally* we'd have the loading images be dependant on how far the > > request has got, but this isn't essential, certainly not for a first > > approximation ... another interesting option would be to show a progress > > bar showing the overall progress, ETA, etc. One thing that *is* critical is > > that we stop loading the images if the user closes the page, but afaics the > > existing infrastructure will do that. > >> > >> On Wed, Jun 17, 2009 at 5:44 PM, sashee<gsashee at gmail.com> wrote: > >> > Ok, thats true. But the browser won't show an image till all the image > >> > above are shown, because it uses 2-3 connections to fetch the images > >> > sequentially. It may happen that a few image that fetches very slowly > >> > will hang all the others, even if they are completely present. > >> > > >> > sashee > >> > > >> > On Wed, Jun 17, 2009 at 4:46 PM, Daniel Cheng<j16sdiz+freenet at > >> > gmail.com> wrote: > >> >> On 17/6/2009 22:36, sashee wrote: > >> >>> .... this way freenet don't start all the > >> >>> fetching, just what is requested... When the page loads, freenet > >> >> ?> start fetching all the images,.... > >> >> > >> >> Did you look at your /config/fproxy page ? > >> >> There is an option called "Enable prefetching of inline images" .. > >> >> > >> >>> What you think? > >> >> > >> >> :) > > > > _______________________________________________ > > Devl mailing list > > Devl at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090618/a705fbe3/attachment.pgp>
