>But here again you are saying that the "fireworks" proposal (thanks for
>whoever suggested that name) is somehow inelegant, or inefficient, yet
>as I have pointed out (and as you have not disputed) it doesn`t result
>in any more messages being sent, in the long term, than your (or any
>other) updating mechanism. Given that, your assertion that it is
>fundamentally unintelligent is unsupported.
Maybe my objection was so juvenile that it didn't warrant debate, but
here it is again. Your argument above seems to assume that the update is
something that the network at large is going to request. In that case
there is no difference in overall network stress. However if someone
updates a file which nobody is going to request, then there is a fairly
big difference in the two proposals.
Under your proposal what would stop a malicious node from sending updates
as quickly as possible to flood the network? Will each node only accept
a certain number of updates from another node per day? As you have said
earlier an informations data should only be proportional to how popular
it is, but the fireworks proposal spreads the document as far as it can
without any test of the document's popularity.
For what neglibible amount my opinion is worth it does not seem like
updates are really that crucial. If you want a newer version of software
(one case where it seems very reasonable to have a version attatched) you
can just search for "Linux Kernel 2.4". Updates just seem to muddy the
waters of what is a very elegant system for storing and retrieving data.
Kevin
________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk! For your FREE software, visit:
http://dl.www.juno.com/get/tagj.
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
