On Friday 19 June 2009 16:18:12 sashee wrote: > No, even javascript cannot send tab closing callback that is reliable. > It can only be achieved with keepalives missing. > Think about system crash when no action can be performed. On that case > the javascript cannot report that it is closed, so it is not reliable.
Sure, we do need keepalives. But can javascript generate an unreliable report that the tab has been closed, that still happens most of the time, and is more or less instant, and if the browser crashes we will have to wait for the keepalive timeout? > > sashee > > On Fri, Jun 19, 2009 at 5:13 PM, Matthew > Toseland<toad at amphibian.dyndns.org> wrote: > > On Friday 19 June 2009 14:48:11 sashee wrote: > >> Ofc not. HTTP is stateless, so in standard ways it cannot be notified > >> when a tab is closed. > > > > Yes I mean with javascript? > >> > >> On Fri, Jun 19, 2009 at 12:28 AM, Matthew > >> Toseland<toad at amphibian.dyndns.org> wrote: > >> > On Thursday 18 June 2009 17:02:06 sashee wrote: > >> >> With async image loading,activelinks will be loaded too. > >> >> As for the 21 secs. It can be decreased, but only to sacrifice > >> >> something else. 21 sec means the client can skip a keepalive, and fail > >> >> after the second. Since it's localhost, it's unlikely to fail even 1, > >> >> so it can be reduced to 11 sec. If we send keepalives more frequently, > >> >> it will consume more resources for all tabs to send them, but it will > >> >> reduce further the time needed to detect tab closes. It is easily > >> >> configured with constants though. > >> > > >> > There is no callback on a page being closed? > >> >> > >> >> sashee > >> >> > >> >> On Thu, Jun 18, 2009 at 11:33 AM, xor<xor at gmx.li> wrote: > >> >> > On Wednesday 17 June 2009 16:36:26 sashee wrote: > >> >> >> Hello folks! > >> >> >> > >> >> >> Some days ago, I've talked with nextgens about toadlet > >> >> >> continuations(it's asynchronous request processing), and he had a > >> >> >> point that when the user opens a site with lots of images, then it > >> >> >> needs many connections open for a long time, and it spawns many > >> >> >> threads at serverside, which is resource demanding and some OSes > >> >> >> don't > >> >> >> allow. The browser has a maximum connection limit to the site, but > >> >> >> the > >> >> >> user can overwrite it. But at the default, firefox opens only 2-3 > >> >> >> connections to fetch the images, this way freenet don't start all the > >> >> >> fetching, just what is requested. So one problem is that if a user > >> >> >> alters the browser's config, then it will result many threads, if > >> >> >> not, > >> >> >> then freenet can't download all the content simultanously. > >> >> >> I think with pushing, I'm working on, can be a solution for both > >> >> >> problems. When the page loads, freenet start fetching all the images, > >> >> >> and the browser gets the progress with 1 permanent connection. There > >> >> >> can be an image eg. "Image is loading...10%" and after some progress > >> >> >> change to 20% and so on, and when finishes downloading, it shows or > >> >> >> says eg. "Image finished loading, click to display". If it's done, we > >> >> >> don't need continuations anymore. Ofc it would need javascript to be > >> >> >> enabled. > >> >> >> > >> >> >> What you think? > >> >> > > >> >> > I filed a bug on that regarding activelinks, containing one possible > >> >> > way to > >> >> > solve it via javascript: > >> >> > > >> >> > https://bugs.freenetproject.org/view.php?id=3207 > >> >> > > >> >> > So when you implement it, please also do it for activelinks, as they > >> >> > are nice > >> >> > to have and could be re-enabled then. > >> >> > > >> >> > xor -------------- 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/20090619/9921e853/attachment.pgp>
