Matthew Toseland toad-at-amphibian.dyndns.org |Freenet Tech mailing
list/Example Allow| wrote:
> 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
> Tech at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/tech/attachments/20100116/1a4fc03f/attachment.html>
