On 6 Oct 2005, at 19:42, Matthew Toseland wrote: > Guido proposed to "move everything non-core out of the node". After > much > discussion, we find that we have the following in common: > > - FCPv2 should be high level to make writing clients easy.
Completely agree. Of course, there is an inevitable conflict between the desire to make an API easy to use, and making it flexible. a layered approach can sometimes be used to address this. > - There should be *some* kind of clean interface between fproxy and > the > node. Fproxy should operate on the same level as frost in the > layering. So long as it doesn't need to run in a separate JVM. > - It probably makes sense to keep client-level code such as fproxy > in a > separate source module. I am mostly in agreement here with Guido. I don't have a problem with that. > > We disagree: > - I am of the view that fproxy should use a java interface class which > can either be provided by FCP or by running in the same VM as the > node, for performance and particularly memory usage. Agreed. > - Guido is of the view that we should use a completely separate VM for > fproxy etc, and let the user switch it on and off easily. No way, JVMs are enough of a resource hog when you just have one of them. > - Guido thinks the node should have a basic HTTP interface for status > etc. I am not convinced. > - I came up with some ideas for a new HTTP container interface using > continuations a while back. This would have various advantages. The > fproxy module could then use this. It would be trivial to > implement an > external container for fproxy to use if it was not running on the > node > itself. So the fproxy module would use two interface classes: > - FreenetClient (implemented by FCPClient or InternalClient) > - WhackyHTTPHandler (implemented by an in-node container or an > external one; either way, it is possible to implement both > blocking > and non-blocking containers; the former is easy, the latter isn't > but would give us the key UI gain that we could have an unlimited > number of parallel requests, if this is needed in future). I think we should have a HTTP interface, but it should be *simple*, today's fproxy is *way* too complicated and has soaked up far too much development time. Ian.
