[freenet-support] Re: Automatic server retry of failing documents

2004-06-22 Thread Michael Schierl
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 it to fetch it...

It might at least try a bit longer. Usually images RNF in only a few
seconds here...

mihi


___
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]


Re: [freenet-support] Re: Automatic server retry of failing documents

2004-06-21 Thread Toad
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 well on the SSKvsCHK site :)
  
  One should not justify a dirty hack by it works pretty well since
  most dirty hacks will...
 
  Why is it a dirty hack?
 
 Do you think it is usual behaviour to put images into IFRAMEs? 
 
 
 I have only seen that on Freenet. And since it is more work (and needs
 more resources on most browsers) and is only done to work around
 another problem, I usually call thinks like this a dirty hack.
 
 So:
 
 - there is a usual solution (IMG tags for images).
 
 - it does not work in a specified environment (Freenet).
 
 - there is no interest to fix that solution in this environment,
   because
 
 - there is a simple way to work around that problem (IFRAME)
 
 - which uses techniques not appropriate for the problem (starting a
   whole HTML parser subinstance just for rendering an image) and
 
 - makes migration of existing work harder (mirroring a website into
   Freenet requires s/img/iframe/)
 
 == dirty hack.
 
 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?
-- 
Matthew J Toseland - [EMAIL PROTECTED]
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.


signature.asc
Description: Digital signature
___
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]

Re: [freenet-support] Re: Automatic server retry of failing documents

2004-06-19 Thread Toad
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 page manually until you have all
   images. (alternatively, you can open a browser window/tab for every
   single image you want to have; IMHO this is no real solution either.)
  
   This is what IFRAME is for :)
  
  One iframe per image? IBTD.
 
  What's IBTD? I beg to differ? 
 
 I thought it to be I beg to disagree, but that is quite the same...
 
  It works pretty well on the SSKvsCHK site :)
 
 One should not justify a dirty hack by it works pretty well since
 most dirty hacks will...

Why is it a dirty hack?
 
 mihi
-- 
Matthew J Toseland - [EMAIL PROTECTED]
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.


signature.asc
Description: Digital signature
___
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]

[freenet-support] Re: Automatic server retry of failing documents

2004-06-19 Thread Michael Schierl
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 works pretty well since
 most dirty hacks will...

 Why is it a dirty hack?

Do you think it is usual behaviour to put images into IFRAMEs? 


I have only seen that on Freenet. And since it is more work (and needs
more resources on most browsers) and is only done to work around
another problem, I usually call thinks like this a dirty hack.

So:

- there is a usual solution (IMG tags for images).

- it does not work in a specified environment (Freenet).

- there is no interest to fix that solution in this environment,
  because

- there is a simple way to work around that problem (IFRAME)

- which uses techniques not appropriate for the problem (starting a
  whole HTML parser subinstance just for rendering an image) and

- makes migration of existing work harder (mirroring a website into
  Freenet requires s/img/iframe/)

== dirty hack.

What is your definition of dirty hack?
 
mihi

___
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]


[freenet-support] Re: Automatic server retry of failing documents

2004-06-17 Thread Michael Schierl
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 a browser window/tab for every
  single image you want to have; IMHO this is no real solution either.)
 
  This is what IFRAME is for :)
 
 One iframe per image? IBTD.

 What's IBTD? I beg to differ? 

I thought it to be I beg to disagree, but that is quite the same...

 It works pretty well on the SSKvsCHK site :)

One should not justify a dirty hack by it works pretty well since
most dirty hacks will...

mihi

___
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]


Re: [freenet-support] Re: Automatic server retry of failing documents

2004-06-16 Thread Toad
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 an option that *if* every tool retried (just
 to make it work in b0rken freenet state) to abuse this by requiring
 tools to do so.
 
 (this argument is a bit like why remove popups on my website? there
 are popup blockers anyway.)
 
 
  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 a browser window/tab for every
  single image you want to have; IMHO this is no real solution either.)
 
  This is what IFRAME is for :)
 
 One iframe per image? IBTD.

What's IBTD? I beg to differ? It works pretty well on the SSKvsCHK site
:)
 
 mihi
-- 
Matthew J Toseland - [EMAIL PROTECTED]
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.


signature.asc
Description: Digital signature
___
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]

[freenet-support] Re: Automatic server retry of failing documents

2004-05-12 Thread Michael Schierl
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 freenet state) to abuse this by requiring
tools to do so.

(this argument is a bit like why remove popups on my website? there
are popup blockers anyway.)


 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 a browser window/tab for every
 single image you want to have; IMHO this is no real solution either.)

 This is what IFRAME is for :)

One iframe per image? IBTD.

mihi

___
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]


Re: [freenet-support] Re: Automatic server retry of failing documents

2004-05-10 Thread Toad
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 not a task for the server?
 
  You sure? I thought we had a meta-refresh tag on those RNF/DNF pages?
  Wont the browser automatically retry the page after a while if you leave
  it to?
 
 Hi again,
 
 wanted to try Freenet again ;-) - seems to work quite well.
 However, those RNFs are really a PITA.
 
 Yes, those RNF pages have meta refresh tags on them; however, that
 does not help if 
 
 a) one does not use Fproxy for fetching a file

In which case whatever you did use would retry.
 
 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 a browser window/tab for every
 single image you want to have; IMHO this is no real solution either.)

This is what IFRAME is for :)
 
 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. But maybe the problem is more fundamental.
 
 mihi
-- 
Matthew J Toseland - [EMAIL PROTECTED]
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.


signature.asc
Description: Digital signature
___
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]

Re: [freenet-support] Re: Automatic server retry of failing documents

2004-05-10 Thread Toad
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 get something, even if the user has gone on to 
 something else. And that, of course, might lead to more RNFs, with 
 obvious potential for regenerative feedback and massive overloading. 
 There seems to be some indication for compromise here.

Not really. RNFs very often mean the request didn't even leave the node.
 -- 
 Roger Hayter
-- 
Matthew J Toseland - [EMAIL PROTECTED]
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.


signature.asc
Description: Digital signature
___
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]

[freenet-support] Re: Automatic server retry of failing documents

2004-05-10 Thread Michael Schierl
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 a FCP app) is no good idea IMHO.

 How would you distinguish messages you don't want very much (like
 possibly non-existent Frost messages) from ones you do want a lot?  

By not using Frost? If that is really an issue, one could specify an
importance flag in FCP. But IMHO that many RNFs are a bug in Fred.

 It
 is likely to generate quite a lot of extra traffic to automatically
 retry all RNFs till you get something, even if the user has gone on to
 something else.

Not until you get something, but for some more time. I guess most
users will not change their mind if they cannot get a site within a
second (which is usual time till RNF for me ATM).

mihi

___
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]


Re: [freenet-support] Re: Automatic server retry of failing documents

2004-05-10 Thread vinyl1
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. But maybe the problem is more fundamental.


I suspect this is the case.  The RNF is coming back much too quickly for the network 
to have been searched to the limit, unless everyone running FN has miraculously 
converted to a T3.

As an experiment, I cut and pasted some not-found keys into FUQID.  Its log file says 
that it is trying 25 HTL, 30 HTL, and 35 HTL, and not finding anything, but it seems 
to be working much too quickly.  

I'm a Win2K transient node on dialup.

-vinyl1



___
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]


Re: [freenet-support] Re: Automatic server retry of failing documents

2004-05-10 Thread Salah Coronya
-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 the
browser or a FCP app) is no good idea IMHO.


 Maybe so. But maybe the problem is more fundamental.


 I suspect this is the case.  The RNF is coming back much too quickly
for the network to have been searched to the limit, unless everyone
running FN has miraculously converted to a T3.

 As an experiment, I cut and pasted some not-found keys into FUQID.
Its log file says that it is trying 25 HTL, 30 HTL, and 35 HTL, and not
finding anything, but it seems to be working much too quickly.

 I'm a Win2K transient node on dialup.

 -vinyl1


The HTL in Freenet is currently capped at 10, so if you inserts anything
higher, it'll automatically be cut down to 10. The failure table on your
node will then see this request failed at HTL=10 and so will immediately
return a DNF.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAn/L2hctESbvQ8ZwRAiC0AKCRB0zFQL1dhlbWC8KNxe6eGs2KlwCfdolN
if3KdmO+fYbgKNDS4dbSiLM=
=/Qr4
-END PGP SIGNATURE-
___
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]


[freenet-support] Re: Automatic server retry of failing documents

2004-05-09 Thread Michael Schierl
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 tag on those RNF/DNF pages?
 Wont the browser automatically retry the page after a while if you leave
 it to?

Hi again,

wanted to try Freenet again ;-) - seems to work quite well.
However, those RNFs are really a PITA.

Yes, those RNF pages have meta refresh tags on them; however, that
does not help if 

a) one does not use Fproxy for fetching a file

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 a browser window/tab for every
single image you want to have; IMHO this is no real solution either.)

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.

mihi

___
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]


Re: [freenet-support] Re: Automatic server retry of failing documents

2004-05-09 Thread Roger Hayter
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 task for the server?
You sure? I thought we had a meta-refresh tag on those RNF/DNF pages?
Wont the browser automatically retry the page after a while if you leave
it to?
Hi again,

wanted to try Freenet again ;-) - seems to work quite well.
However, those RNFs are really a PITA.
Yes, those RNF pages have meta refresh tags on them; however, that
does not help if
a) one does not use Fproxy for fetching a file

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 a browser window/tab for every
single image you want to have; IMHO this is no real solution either.)
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.
mihi

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 get something, even if the user has gone on to 
something else. And that, of course, might lead to more RNFs, with 
obvious potential for regenerative feedback and massive overloading. 
There seems to be some indication for compromise here.
--
Roger Hayter
___
Support mailing list
[EMAIL PROTECTED]
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:[EMAIL PROTECTED]