Re: Fred and FProxy

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.

_______________________________________________
Tech mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAABCAAGBQJLR6oEAAoJEHsvjZi+xPTDcEAQAMBFJ15vMh6NARROp+U5hZlw
/0m50wvGr6dRQx++QxkglEj3Hoovc+lA/8RG6vw9YaiflgsqwaegZCCyR/mwpkA9
d3laCb5nnBiA4gZ0J3m1Wn0JRLw126Fikp/NXydWt7eOdAPKFlz71W7mp1rm0Ci6
ndiD8D6YgXWt58L6uN+v9FwaTcfxg9Ve4JeXZcN6ADyEBpnSKu9ZcEcVWqsT3Nfu
dhd65afyeiEWW19sr984dtQG4m6YhoVHkR4BsWs7IusJuvxG5ida3j6IK0SdRJp1
EhQUDWooELR+5MOCkrghPNlvRS/JBDo8U27m+Jqh1FsNTCxExWk2GekYX/b6JKTC
8OeXH7ndLa+4Av0reFOmdPaY2lPChO4EWvQyO4peQlWP6dhb9mIaPnm1gPC/oS3y
mOTTCdCq5IAWdmK5VqgpKdDkvMuu5S0V4V+kyYlX689ZOmI1GN952T6zYv//HM4Q
2HKVKFSVhojwDlwv/LmCitkCS3ztvC5wklKyHxcy91wU61lKqoP4eL8ICSrYS+hR
tWCXnkrXfAtXJHkNHCwtRIFXWBwcXiV3lrkF0mfffO69OXz1LkY/vRMratRjANUR
8qp+QNF3KI5b7vDsiNfNsn1CdjFbZkhXCS36HDBtUdxjESLfBCHci/H42PV+WwdR
KfN3rrZRLZ9yuDuer9km
=gYZQ
-----END PGP SIGNATURE-----