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
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.
sashee
On Fri, Jun 19, 2009 at 5:13
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 wrote:
> > On Thursday 18 June 2009 17:02:06 sashee wrote:
> >> With a
Ofc not. HTTP is stateless, so in standard ways it cannot be notified
when a tab is closed.
On Fri, Jun 19, 2009 at 12:28 AM, Matthew
Toseland 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 decre
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
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.
sashee
On Fri, Jun 19, 2009 at 5:13
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 wrote:
> > On Thursday 18 June 2009 17:02:06 sashee wrote:
> >> With a
Ofc not. HTTP is stateless, so in standard ways it cannot be notified
when a tab is closed.
On Fri, Jun 19, 2009 at 12:28 AM, Matthew
Toseland 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 decre
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 unlikel
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
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 unlikel
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 lon
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
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 lon
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 us
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" ..
> Wh
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
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.
On Wed, Jun 17, 2009 at 5:44 PM, sashee wrote:
> Ok, thats true. But the browser won't show an image till all the image
> above are shown, because it us
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
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, 2
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 us
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 r
On Wednesday 17 June 2009 15: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 lo
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
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
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.
On Wed, Jun 17, 2009 at 5:44 PM, sashee wrote:
> Ok, thats true. But the browser won't show an image till all the image
> above are shown, because it us
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, 2
On Wednesday 17 June 2009 15: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 lo
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" ..
> Wh
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 r
30 matches
Mail list logo
