> Pro: > * The thread-limit - each HTTP connection costs a connection, and we > cannot afford them, because we can't use as many threads in a single > VM as we want to.
a) Why not? b) This won't be an issue when me move to nio > * In general, Fproxy etc wouldn't interfere with Fred's resources The computer as a whole would have less resources, since it would have two VMs running. Resource management within the Freenet VM is just a question of doing things right. > * Possible to restart Fproxy without restarting Fred Why would this be so valuable? > * Easier to implement alternate interfaces such as a browser plugin if > _everything_ is exposed by FCP. True, but we don't need to run Fproxy in a separate VM just to expose everything via FCP. The original intent was to have both a FCP sockets interface (as we do), and a parallel FCP Java API (as we don't really) which could allow plugins to run in Fred's JVM. > * Easier to make alternate implementations of the node. Or make radical > changes to Fred without making corresponding changes to Fproxy - for > example, the long-heralded nio. If the API which FProxy uses to talk to the node parallels FCP then this will be the case anyway. > * People who only use third party FCP clients don't need to run the > Fproxy VM at all. They wouldn't need to run the FProxy plugin either. > * Possible to create a package with only the node, and a package with > only Fproxy, if wanted. We could create a package which didn't include the FProxy plugin if we wanted too. > * Considerably easier to run the client side on a different machine to > the server side. Than what? Pointing your web browser at something other than 127.0.0.1? > Comments? I don't think any of the benefits outweigh the additional resource consumption that would be required for two JVMs. We take enough crap over resource usage as it is. Ian. -- Ian Clarke ian@[freenetproject.org|locut.us|cematics.com] Latest Project http://locut.us/ Personal Homepage http://locut.us/ian/
msg06647/pgp00000.pgp
Description: PGP signature
