* Ian Clarke <ian.clarke at gmail.com> [2008-05-16 09:35:34]: > On Fri, May 16, 2008 at 9:27 AM, Florent Daigni?re > <nextgens at freenetproject.org> wrote: > >> But the same argument could be used in my Java analogy. Java has a > >> far higher profile than many apps written in Java, but it doesn't > >> follow that Java should bundle all of these apps. > > > > Heh, java has a frozen API... last time I checked ours is neither frozen nor > > even versioned! > > How is that relevant to this discussion? >
If you want freenet to be a framework people actually use to write applications for, then it has to be versioned and to provide some level of backward-compatibility in between minor versions. > > [snip.] > >> > If you did want to push Freenet-the-service, rather than > >> > Freenet-the-program, I'd suggest that for the late .7 and early .8 you > >> > continue the focus on making the install simpler.. For example, the > >> > project could create a Freenet-for-embedded.zip, which defaults to > >> > opennet only, auto-detects it's IP, and joins the network when the .jar > >> > is run, rather than asking the user any questions. > >> > >> Well, I've been describing Freenet as a platform since around 1999 - > >> there is nothing new about this. I think we do need to do some work > >> to make Freenet more easily embedded, possibly as you suggest. > >> > > > > 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. The configuration framework is accessible from FCP... Some applications like Thaw are already using 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. > Well, if you want freenet to run on embedded systems you will have some tradeoffs to make at some point... I do think that fproxy and its dependencies (the content-filter could be pluggable too) are nothing but overhead. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080516/7584bb6b/attachment.pgp>