On Tue, 09 Oct 2001, Ian Clarke wrote: > > > > > >>There is no reason that this option would have to be obscure in my > >>proposal, and no reason why this option might not be obscure with your > >>proposal, so this point doesn't differenciate the two in any way. > >> > >In your proposal it's a menu option somewhere that people might not > >notice, or might just not use, because it doesn't request a file for > >them. > > > Huh? There is nothing in my proposal which requires it to be an obscure > option, and nothing in your proposal which prevents it from being an > obscure option. The bottom line is that the ultimate decision will rest > with the client writers either way - so debating over how it might be > presented to the user is irrelevant. > In my proposal, it is presented to the user in big bold letters what's going on as they install. It's not a client issue in my proposal. In your proposal, it's a client issue. Writing a GUI client (that being the important kind for windows), I definitely wouldn't waste much UI space on an option that's going to be run once per installation of freenet. Thus it's going to be obscure if we do it your way. Especially if it's part of the taskbar icon.
> >>>2) doesn't require shutting down the node to accomplish > >>> > >>The same is true of my proposal. > >> > >If you're saying that the taskbar icon should be able to talk FCP to do > >this without restarting the node, I claim that's a bit absurd. > > > I gave one example of how this might be used, which was that the taskbar > code could provide this functionality, in which case it would need to speak > FCP. What is absurd about that? > Our first taskbar icon was written in assembler. I'm not saying that it'd be a big job making the taskbar icon talk FCP, but I am saying that it's quite unnecessary. > >It's really easy for a user to re-install freenet and still be handing > >out the old reference with your proposal. > >With my proposal, the user is forced to create a new reference if they > >re-install. > > > That is rubbish, it is entirely a question of how clients are implemented, > and irrelevant to this debate. A user who takes the seed.ref file created > on node startup and put it on their website could just as easily forget to > update their website when they reinstall regardless of whose proposal is > used. > True. But they are forced to realize that the new node reference will be different from the old one if the installer forces them to make a new one, whereas if it's just an option on a related program, there's no logical connection between the installation of the node and needing a new ref, which is bad. > >>Can you give me one, just one reason that your proposal is preferable > >> > >I hope I've given you three reasons. > > > No you haven't - you have simply made assumptions about how client > writers might implement this, and then attacked my proposal on the basis > of how you conveniently assumed a client writer would do things, however > I could just as easily make the same assumptions in reverse and turn > your argument on its head. > > Ian. > /me realizes that responding to this last part would quickly put us in the "flame war" category. Thelema -- E-mail: thelema314 at bigfoot.com If you love something, set it free. GPG 1536g/B9C5D1F7 fpr:075A A3F7 F70B 1397 345D A67E 70AA 820B A806 F95D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20011010/fd117a0d/attachment.pgp>
