On Thursday 07 January 2010 19:17:31 Peter Reineke wrote: > Hi > > There already have been, at some point, discussions about whether it is > useful to separate Fred and Fproxy. I would like to revive the idea by > adding some ideas. > But as time has passed since the last time I read the code, I have to > make sure my perspective on there Freenet architecture is correct: > > 1. There is FRED the daemon which contains the main components to build > a node in the Freenet network. FRED has an Interface (FCP Spec 2.0) > which allows applications like Thaw and Frost to use the basic network > services of FRED, like inserting or retrieving a file. > > 2. FProxy is the part of Freenet which offers the HTTP-Frontend to the > Darknet. Its main task is to translates the content hashes into URIs an > URIs back to content-requests, but it also offers some webrepresentation > of FREDs configuration files.
And content filtering. Which is exposed via FCP - I'm not sure where it should go if we split it up, probably in a plugin. > > 3. Fproxy does not use the FCP interface, but is strongly coupled with > FRED. > > Please correct me if I am wrong. > > I think it is best to have the Freenet Core and FProxy decoupled for two > reason: > > a) It is generally better do have loose coupling. As components can be > developed, tested and debugged in separate. [I think this point has > already been discussed] > > b) The FProxy could be useful for a variety of other projects. Other > content based distribution schemes could profit from it, as FProxy could > profit from these projects. > > Let me explain that: > > Freenet is only one kind of network which allows to store content and > retrieve it via a hash key. Other networks like Emule and bittorrent > also use hash keys to address files. FProxy should work with these > networks as well. > As Freenet's focus is anonymity and security it is outperformed by less > secure networks, which therefore maintain a good ratio of the "market > share". If FProxy would be able to offer a web interface to, e.g. emule > files it would get the attention of user's to which Freenet is too slow. > (Attention is good as it provides with user reports, volunteers and > leads to maturity). FProxy could be a separate project and be enhanced > in separate. > > Maybe even FCP could be generalized in this way so that there is a > bigger market for FCP clients. IMHO eventually fproxy should be a plugin, talking to the node inside the same JVM but using a well-defined well-documented interface that is also used by other plugins. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20100108/3d0809d3/attachment.pgp>
