[Tech] Cache and Store

[Florent Daignière]

* Bob Ham <rah at bash.sh> [2007-05-11 08:19:49]:

> On Thu, 2007-05-10 at 22:47 +0200, Florent Daignière wrote:
> > * Bob Ham <rah at bash.sh> [2007-05-10 21:45:59]:
> > 
> > > On Thu, 2007-05-10 at 12:53 +0100, Matthew Toseland wrote:
> > > > On Thursday 10 May 2007 11:52, Florent Daignière wrote:
> > > > > * Matthew Toseland <toad at amphibian.dyndns.org> [2007-05-10 11:31:22]:
> > > > > >
> > > > > > As long as it's an expert option, I don't see any reason why it shouldn't
> > > > > > be accepted.
> > > > >
> > > > > Preventing users from their stupidity ?
> > > > >
> > > > > We don't want everyone to have a cache but no specialized data on the
> > > > > basis that "with a bigger cache downloads are 'resuming' ; I don't care
> > > > > about others nor the network so I only cache"
> > > > 
> > > > Fair point. If they want to break their node that much they can maintain a 
> > > > fork.
> > > 
> > > This is a real cognitive problem showing up right there.  It isn't your
> > > responsibility to second-guess the user.  There are valid reasons for
> > > the node to have this functionality.  The only reason for it not to is
> > > to inhibit users.  That's what Microsoft do.
> > 
> > Indeed... and experience has shown that it works.
> 
> What do you mean "it works"?  What does it work to do?
> 

Shall I remind you that most of our users do use Microsoft products and
are happy with them ?

I'm  against the  introduction of  new useless  (no need  to debate  the
meaning of useless this time; show me some stats/simulations if you want
to be heard)  settings, especially when they can harm  the network... So
far we don't  have content reachability problems and if  we did, I would
suggest to fix the datastore code or  to prevent users from nuking it on
a regular basis.

The  50%-50% limit  is arbitrary,  so  are many  "unknown" and  "hidden"
settings in the node; unless you  have strong evidence (with a theorical
basis) explaining  why it's bad/wrong  you will  be directed to  the bug
tracking system and  the "wishlist" category. I will ask  you to explain
the "This  is a problem."  in your  first mail [1]  as well (so  that we
could at least agree on the fact  that we don't have the same definition
of what a problem is either ;) ).

Moreover  some related  work  has  to be  done  on  the shrinking  code,
mroggers  has suggested  that  the  LRU policy  might  not  be the  best
solution  to  choose which  data  will  be  pruned;  he came  with  some
references and  is likely to be  heard... You didn't, did  you ? Anyway,
consequently his suggestion is likely to be implemented before any other
"related" work is done  in that area of the code.  IMO we shouldn't give
users incentives to use a "maybe broken and harmful" schrinker, hence
I'm against letting him play with the ratio of the cache/store.

NextGen$
[1]
http://archives.freenetproject.org/message/20070503.152148.95c943dd.en.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/tech/attachments/20070511/d058e73c/attachment.pgp