This is an interesting idea. Anything that will make the code more modular, and seperate the core from the user interface is good.
The JAR is pretty bloated, is Freenet really that more complex (say over...other java based anonymous p2p systems like AntsP2P or I2P). Also making it modular, would that allow for other clients more easily access the Freenet datastore? Having the datastore available to other applications (like something running over I2P) would make Freenet 0.7 the default distributed content store format for anonymous applications. On 9/18/05, Guido Winkelmann <guido-frn at unknownsite.de> wrote: > > Hi, > > I have a proposal to make with regard to the development of 0.7: > > Let's remove everything that's not strictly essential to the operation of > the > node from the code of fred 0.7 and write an external daemon to support > these > functions, that communicates with the node via FCP (and/or something > similar > for Freenet streams). Let's call that daemon fad, "Freenet accompanying > daemon" for now. > If 0.7 should be done this way, the mentioned external daemon should, of > course, come bundled with the standard Freenet package. A stripped down > fred > on its own would be of no use to most, just like a TCP/IP stack on its own > - > or i2p... > > Things that should be thrown out that are present in current versions > (5xxx) > include: > > - The Web interface (definitely - but it might be wise to leave a stripped > down version for strictly node-maintainance related purposes.) > - The Distribution Servlet (definitely) > - Everything related to splitfile handling (maybe, more talk on that > further > down) > - The command line client (I don't think there's a good reason to include > that > in the normal freenet.jar) > and maybe other stuff I don't know about. > > The advantages to this approach are: > > - The node source code becomes smaller and easier to maintain. > - The operation of the node becomes more reliable. (There is less stuff in > there that might cause it to crash.) > - Resource consumption of the node will be lower and much more > predictable. > - The code for enduser related functionality becomes a lot more accessible > for > new programmers. (Patches to fad are pretty much guaranteed not to > interfere > with the node's core operations and, thus, are more easily accepted.) > - The external daemon can be written in a language other than Java > (Whether > that's an advantage may depend on your POV. IMO, it's a big one.) > - Third party implementations of the node itself can be done more easily. > (The > programmers won't have to rewrite all of the most basic user interface > stuff > from scratch) (I think this is a pretty important issue in long run.) > - We can draw a very clear line between what's enduser stuff and what > isn't. > (And the node should not be enduser stuff. Install it, configure resource > restrictions, start it, stop it should be the sum of the cases where the > (opennet-) enduser has to interface with it.) > - Fred can finally become a lean and mean unbloated routing machine. > > Disadvantages: > > - The project needs to make extra sure that "fad" really is in a usable > state > before it can release 0.7 > > About splitfile handling inside or outside the node: > > In my opinion, there are two sensible ways one could go with regard to > splitfiles: > > - Make the node completely ignorant about splitfiles, having it all done > on > the client side. This has the advantage that the node becomes simpler and > slicker and the disadvantage that clients become more complex. In the > worst > case, we may end up with several incompatible splitfile handling > algorithms > floating around. (This might be countered by releasing easy to use > libraries > for splitfile handling early on.) > Also, splitfile handling is a very resource intensive operation. People > might > want to delegate it to a different computer. > (At least on my current node, splitfile decoding/encoding is the most > common > cause for OutOfMemory errors.) > > - Handle splitfiles completely inside the node, completely abstracting it > away > from clients. In this case, programmers of third party tools won't even > have > to be aware of the fact that fred internally only handles blocks of 32 > KiB. > FCPv2 can be simpler, client apps can be a lot simpler. > > The current situation, where node and client cooperate over FCP on the > splitfile handling is (still imho) the worst one can do. > > Thus far for my proposal. Comments would be appreciated. > > Guido > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/tech > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20050919/9910f97e/attachment.html>
