On Friday 16 May 2008 15:35, Ian Clarke wrote:
> On Fri, May 16, 2008 at 9:27 AM, Florent Daigni?re
> <nextgens at freenetproject.org> wrote:
> >
> > What about fproxy; shall it be separated from fred too ? I think it
> > should be a plugin to the node.
> 
> Fproxy is the means through which the node is configured, so it
> doesn't make sense to separate it.  Technically the freenet->http
> aspect of fproxy is a client app, but since its already tightly
> integrated, and since it is serves as a "gateway" to Freenet, it makes
> sense to keep it part of Freenet.

It is not tightly integrated. The freenet to HTTP layer is a relatively thin 
veneer over the client layer. And eventually all of fproxy should be a 
plugin, connected to the rest of the node via a well defined API that can be 
implemented either internally (for speed) or through FCP. At least, it should 
be if elegance is important. Since it isn't, it won't be.

The Freenet to HTTP layer would be vastly more useful *to a typical end user* 
with a few tightly integrated plugins. These could be maintained 
independantly, and integrate through well defined APIs. This would allow:
- Searching of freesites ("google").
- Embedded forums ("google groups").
- Webmail ("gmail").

Getting rid of plugins, at least in terms of getting rid of the plugin API, 
will really *not* help matters. Right now, there aren't hundreds of Freenet 
client apps, there aren't even dozens of Freenet client apps. There are a 
few. There will be more if Freenet is popular, but if it is not easy to use, 
and useful, it will never be popular. And if we stop bundling apps which are 
critical to Freenet being easy to use and useful, this will *reduce* 
Freenet's popularity.
> 
> Ian.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20080516/d2c17fed/attachment.pgp>

Reply via email to