because the main-post is too long already i moved out this part.
thoughts about client-handler:some years ago i wrote a app (named 'metafront' for further references) like
flux for edonkey/overnet-clients. (it was very very low indeed, didnt use any
db, had no multi-user,... but had the same basic concept : webfrontend to operate a client)
one part (the frontend) were perl-cgis.
in userland doing the "same" like tflux. see/operate your "seeds+leeches".
the other part was a "control-wrapper" (a perl-daemon) for the
ed2k/overnet-client. (this was based on code from ocbMaurice in case someone
remembering that.)
what that daemon actually does is:
- starts up core and pipes stdin and stdout under script control
- stdin and stdout accessible via a socket from script
this is where the approaches differ :
- flux uses stat-file as the interface to communicate with clients
- metafront used the perl-daemon to communicate with the metamachine-client.
the perl-cgis connected to the the daemon via the open socket and
"communicated" "directly" with the core (proxied by daemon).
means cgis were sending commands and parsing + displaying returns.
advantages of this approach are there is no need to patch the client (which was
not possible because metamachine code is closed source) and client/frontend dont
need to be on the same machine.
dis-advantage is that you need to write ugly parsing code to parse the cores
return. (gettin even nicer when client-versions output in different formats)
so why this story about an old code ?
i tried to do the client-handler-design in a way that integrating
clients with complete different interfaces should be possible.
afaic in theory writing a client-handler-implementation for a client like
azureus (commons-cli) may be done without hacking azureus. (quite some work of
course, but may be possible)
you can virtually do anything in the subclasses. all you need to serve public
are "getters/setters" for the "values" and in case of class ClientHandler
itself methods for operation of the client(s).
how you really get values and if its based on any concept like a "statfile"...
is encapsulated in the handler-classes.
the ClientHandler-implementation may not start a new process for a client but
send a "start-command" to a "multi-torrent-client".
note : i dont have in mind doing this as i dont really need it. would be a
nice to have but is no must for me. if someone wants to dig into it
and wants to take a look at the metafront code drop me a pm. (but dont
expect too much. its old and no good code.)
note : these are only thoughts and i cant really say if it would really work well
or would integrate well in torrentflux. additionally "external" tools
using stat-files (like fluxpoller.pl) would have a hard time then.
b4rt