Am Donnerstag, 6. Oktober 2005 20:30 schrieb Matthew Toseland:
> On Thu, Oct 06, 2005 at 07:24:07PM +0200, Guido Winkelmann wrote:
> > Am Dienstag, 4. Oktober 2005 13:19 schrieb Matthew Toseland:
> > > On Mon, Oct 03, 2005 at 02:00:52PM +0200, Guido Winkelmann wrote:
[...]
> > > > > > - The command line client (I don't think there's a good reason to
> > > > > > include that in the normal freenet.jar)
> > > > >
> > > > > It's tiny, and it's a useful debugging tool. There is no compelling
> > > > > reason to include it in the jar except to save 10kB or whatever it
> > > > > is. Which is insufficient reason given Fred's memory footprint!
> > > >
> > > > Well, this is not an important part of the whole discussion anyway,
> > > > but I still think it should get it's own .jar. Having to call it by
> > > > its class name from the freenet.jar may be intuitive for Java
> > > > programmers, but not to anyone else. This isn't how how things
> > > > usually work on the commandline, usually you have one utility = one
> > > > binary. The way it is now, most people won't even know there is a
> > > > supplied cl client.
> > >
> > > You can provide one binary if you want to. Just like you can provide
> > > one binary for Fred.
> >
> > It might actually be best to simply provide a small shellscript (or .bat
> > file for Windows) as a wrapper for it.
>
> start-freenet.sh?
... is a wrapper for starting fred. I was talking about the same thing for the
command line client used for inserting and retrieving files from the command
line.
[...]
> > Where did I say that? Nobody is talking about making FCP2 even more
> > complex. Actually, I think your current plans for FCP2 are too complex
> > already. (Multiplexing? Why would we need that? We already have perfectly
> > good multiplexing on the TCP/IP-level, that's more efficient and more
> > robust than yours will ever be.)
>
> It's also *far* more expensive. There is no reason to slow things down
> here, and I don't see that it makes life harder for the client author.
Multiplexing done by TCP/IP is expensive? That's big news for me. Maybe you
should tell that the BitTorrent crowd and, oh, just about the rest of the
internet.
[...]
> So you are punishing the users for running fproxy, because you don't.
You are still clinging to the assumption that fproxy will stay the most
important application in Freenet for a long time to come. Personally, I am
convinced that it will be dwarved in importance by IRC-over-Freenet and/or
Messageboard-over-Freenet soon after good tools become available for that. (I
don't consider Frost to be a particularly good tool.)
Note that the popularity of the WWW on the normal web is in no smll part due
to the ability to do server- and or client-side scripting, which is simply
not available in Freenet.
[...]
> > > What we are doing - implementing
> > > easy to use, high level interfaces that hide the complexity of
> > > splitfile decoding from the app, implementing new services other than
> > > store and retreive, and implementing and bundling basic communication
> > > tools such as IRC, email and ideally CVS - will help to get new tools.
> > > Making everyone code a redundant several thousand lines of code in
> > > their apps just to save on memory usage when the user never uses
> > > splitfiles is ridiculous.
> >
> > Right. But noone was suggesting this.
>
> Okay, so you accept that we need a high level FCPv2. Good.
I didn't "accept" or "admit" anything. I never was opposed to a high-level
FCPv2 in the first place, I simply presented a few options that might include
a low-level one. The only thing I'm "admitting" is that there was a
communication issue here.
[...]
> > A real solution would involve making it a rare occurence to actually have
> > to ask. This involves good docs, but also structuring the projects code
> > in a way that makes it easy to understand and work with, even for
> > newcomers.
>
> Which does not necessarily mean dividing it into many independant modules.
Not necessarily, but this could help a lot.
[...]
> > > End-user code such as?
> >
> > Everything that actually does something for the user with the
> > functionality provided by FCPv2. I'd classify enduser code (in this case)
> > as "anything that is or could be implemented using FCP(v2)".
>
> Ahhh, okay. So:
> - Fproxy is end-user code.
> - The config servlet is end-user code. Even though the user needs to run
> it to configure bandwidth usage in a user-friendly way.
> - Diagnostics are end-user code (you can get them from FCPv2).
The last two don't neatly fit into the scheme core code - enduser code.
They're a special case.
> - HTTP in general is end-user code.
[...]
> > > Einstein once said that the trick with Occam's Razor (~= KISS) is not
> > > to slit your own throat. Things should be as simple as possible - AND
> > > NO SIMPLER.
> >
> > Alright - so we're arguing about where the point of "too simple" is.
> >
> > Oh, and if I got this correctly, the thing from Einstein was about
> > something different. It was about educating the public about science's
> > discoveries. If you're getting too complex in this case, the audience
> > won't understand. If you're getting too simple, you're losing
> > correctness.
>
> Really? I had always assumed he meant theories... Occam surely did...
As far as I know, it isn't even known for certain whether it really was
Einstein who said that. It doesn't matter much, though. There is wisdom in
this quote, so who cares who said it originally?
[...]
Guido
