Toad [EMAIL PROTECTED] writes:
What is your definition of dirty hack?
Fair enough. Would you say that the solution is to make sure the images
load the first time from IMG SRCs?
If that were possible, sure. At least if they are available. If not
(like edition headers), Freenet will not manage
On Sat, Jun 19, 2004 at 11:03:18PM +0200, Michael Schierl wrote:
Toad [EMAIL PROTECTED] writes:
On Thu, Jun 17, 2004 at 06:33:22PM +0200, Michael Schierl wrote:
Toad [EMAIL PROTECTED] writes:
[putting every image into an iframe to work around Freenet's
reloading bugs]
It works pretty
On Thu, Jun 17, 2004 at 06:33:22PM +0200, Michael Schierl wrote:
Toad [EMAIL PROTECTED] writes:
On Mon, May 10, 2004 at 10:17:30PM +0200, Michael Schierl wrote:
Toad [EMAIL PROTECTED] writes:
b) the failing file is an image. In that case it just disappears and
you have to reload the
Toad [EMAIL PROTECTED] writes:
On Thu, Jun 17, 2004 at 06:33:22PM +0200, Michael Schierl wrote:
Toad [EMAIL PROTECTED] writes:
[putting every image into an iframe to work around Freenet's
reloading bugs]
It works pretty well on the SSKvsCHK site :)
One should not justify a dirty hack by it
Toad [EMAIL PROTECTED] writes:
On Mon, May 10, 2004 at 10:17:30PM +0200, Michael Schierl wrote:
Toad [EMAIL PROTECTED] writes:
b) the failing file is an image. In that case it just disappears and
you have to reload the page manually until you have all
images. (alternatively, you can open
On Mon, May 10, 2004 at 10:17:30PM +0200, Michael Schierl wrote:
Toad [EMAIL PROTECTED] writes:
a) one does not use Fproxy for fetching a file
In which case whatever you did use would retry.
Not necessarily. Scripts talking FCP via netcat most likely won't...
And, I think it is not
Toad [EMAIL PROTECTED] writes:
a) one does not use Fproxy for fetching a file
In which case whatever you did use would retry.
Not necessarily. Scripts talking FCP via netcat most likely won't...
And, I think it is not an option that *if* every tool retried (just
to make it work in b0rken
On Sun, May 09, 2004 at 04:20:22PM +0200, Michael Schierl wrote:
Niklas Bergh [EMAIL PROTECTED] writes:
Now I believe I can live with freenet being slow and that
many documents are not immediately available. What is
annoying me is that _I_ will have to do the retrying. Why is
that
On Sun, May 09, 2004 at 09:52:21PM +0100, Roger Hayter wrote:
How would you distinguish messages you don't want very much (like
possibly non-existent Frost messages) from ones you do want a lot? It
is likely to generate quite a lot of extra traffic to automatically
retry all RNFs till you
Roger Hayter [EMAIL PROTECTED] writes:
Michael Schierl [EMAIL PROTECTED] writes
For me it seems as Fred is too fail-fast. It may try for a few more
seconds or minutes instead of returning the RNF nearly immediately
(and very often). Putting that retry to the user's side (being it the
browser or
Toad [EMAIL PROTECTED] replied:
For me it seems as Fred is too fail-fast. It may try for a few more
seconds or minutes instead of returning the RNF nearly immediately
(and very often). Putting that retry to the user's side (being it the
browser or a FCP app) is no good idea IMHO.
Maybe so.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
vinyl1 wrote:
Toad [EMAIL PROTECTED] replied:
For me it seems as Fred is too fail-fast. It may try for a few more
seconds or minutes instead of returning the RNF nearly immediately
(and very often). Putting that retry to the user's side (being it
Niklas Bergh [EMAIL PROTECTED] writes:
Now I believe I can live with freenet being slow and that
many documents are not immediately available. What is
annoying me is that _I_ will have to do the retrying. Why is
that not a task for the server?
You sure? I thought we had a meta-refresh
In message [EMAIL PROTECTED], Michael Schierl
[EMAIL PROTECTED] writes
Niklas Bergh [EMAIL PROTECTED] writes:
Now I believe I can live with freenet being slow and that
many documents are not immediately available. What is
annoying me is that _I_ will have to do the retrying. Why is
that not a
14 matches
Mail list logo
