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
