Colin Davis skrev: > Zero3- I appreciate the suggestions you've made, and I'm sorry that > you seem to be butting heads a bit. >
Yea :-/. Thanks though. > 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. > 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. > > 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. > > 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. > > 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. > > 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. > That's a good point. My main concern isn't really which of those 2 classes Freenet belongs to, but the simple situation of downloading things during the installation. I think that stuff should either be bundled or downloaded separately. Had Freenet been something else than what it is, I might have argued for an online installer instead, but Freenet being Freenet makes me go for an offline. The size cost of bundling plugins and seednodes are less than 5%, so always downloading those things and asking about them in the installer (as we are going to) seems like a good solution to me. In any way, all I want to prevent is downloading them during the installation :) > 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, a GUI installer like > yours or the old NSIS installer for Windows, and native packages (rpm/ > deb) for Linux. > 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. > That's a fair argument. Obviously, I cannot do much more than stating my intentions (which is to maintain my installer as long as needed), but we all know that the world changes, and people change priorities and disappear every day. That's always the risk you take, really, isn't it? But by me doing an extra effort in creating a native Windows installer doesn't prevent keeping Windows support in the cross-platform installer as a fallback - should I suddenly disappear and nobody would be willing to maintain my installer. This is how I think about it: You can either have the current solution, or have it *plus* a native Windows installer. Worst-case scenario is that you scrap my native installer and go back to how it is now. The cross platform installer isn't going away anytime soon as it's needed for both Linux and Mac too. toad is, btw, making changes to move configuration to the first-time wizard, leaving much less maintenance on the installer side. Hopefully, the installers will barely have to be maintained at all. - Zero3
