On Friday 12 December 2008 02:23, Colin Davis wrote: > Zero3- I appreciate the suggestions you've made, and I'm sorry that > you seem to be butting heads a bit. > > I tend to agree with you that the installer should default to having > as much as a user might reasonably need- To my eyes, this includes at > the very least the Librarian plugin, since I think that searching > should be made prominent in the UI.
As far as I know this is included in the default plugin list. > It should also probably include the Spider plugin, so that users can > easily create their own indexes to search, as well as publishing them > to their flog. I disagree, very few users will want to run an index. > > The other plugins don't really belong in most people's installs. SNMP, > and tests won't be used my many people, and MDNS shouldn't be on > without the user explicitly asking for it, since it's potentially > unsafe. Depends on your threat model. If you have untrusted users on your LAN, you have problems. On the other hand it does make life a lot easier in some cases. We should ask the user whether they have untrusted users on their LAN in the setup wizard and if not let the LAN use fproxy ... but there were some complications implementing this the last time we tried. > > Freenet should also bundle a jSite-like tool, as part of the web- > interface, and the FMS and FMS-email tools. > This allows users full control over the Freenet experience. Agreed. > > What would be nice is if there were an official way to download > additional plugins over freenet, once the node were up and running; > That way these, and others as the project grows, could be easily > added, akin to firefox Extensions. Updating plugins over Freenet also implies downloading them > > Part of the problem, Zero3, is that there is STILL a lot of debate > about where to draw the line between application and platform with > freenet. > > If Freenet is an application, of COURSE it should have most of the > plugins included by default- It needs to be something that people want > to use. > If Freenet is a platform, the installer should be as minimal as > possible, so that it's easy to bundle and doesn't impose it's own UI, > instead relying on the applications that use it. This has, to my eyes, > long been a contentious issue, so don't take it personally. > > On your second issue- Ian has made it pretty clear that he wants to > simplify the install process. The most user-centric way to do this is > to do separate native installers for every platform. A DMG for OSX > that then gives a "Drag this to install" app, We would apparently need an OS/X specific script to run when the user first runs Freenet, which would auto-install Java (since they may only have 1.4 and we need 1.5), install an autostart item, start the node, and then run browse.sh to do the rest. > a GUI installer like > yours or the old NSIS installer for Windows, and native packages (rpm/ > deb) for Linux. It is unlikely that we will be able to maintain packages for EVERY linux distro. Some don't even use packages. > The problem is, these take a LOT of work to make, and that work has to > be maintained. > > The project has seen people make installers before, and then vanish... > This is worse than not having one in the first place, since it then > means that there is an unmaintainable system in place, and the > project gets stuck when they need to update them. Exactly. Unmaintained code is bad code. Part of the equasion is minimizing maintenance by doing as much as possible in the cross-platform Java code. > > Thanks, > Colin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20081212/1c07fcc6/attachment.pgp>
