acmeattic-devel team mailing list archive

[Karthik Swaminathan Nagaraj <nkarthiks@xxxxxxxxx>]

I want to step back for a moment to discuss the need for a "separate"
daemon.
I agree that the daemon has contained functionality and its a good idea to
keep it separate from the UI. However, what is the need to have it as a
different process? Both (I assume) are going to be written in Python and are
part of the same AcmeAttic binary.
In the command line context, it makes some sense to have a separate process,
as the UI console is usually short lived and on user action. However, on a
GUI app, these can be built into one and the daemon can run as a separate
thread(?) and the app can just be pushed to the background (similar to
common apps such as bittorrent, amarok).


   - In order to address concerns on IPC, I always advocate the use of the
   Network. The daemon could listen on some port and we can do a local network
   connection. Look at this discussion on
Stackoverflow<http://stackoverflow.com/questions/656933/communicating-with-a-running-python-daemon>.
   Pyro <http://www.xs4all.nl/%7Eirmen/pyro3/> is a possible solution for
   RMI style communication. Btw, Remote Method Invocation (RMI) handles all the
   "hard/unclean" network communication and exports a simpler object based
   interface for OOPS fans. Its slower than direct network, but performance is
   not an issue for small messages. (Pyro is platform independent, and so is
   bare network). Deluge is a popular bittorrent client which is daemon based
   and the clients talk to the daemon through the network.
   - IMHO, writing protocols that can perform simple atomic operations is
   much simpler than (trying to) thinking of all possible interleaving of
   messages and associated Race conditions. I've done quite a bit of
   Distributed systems debugging, and the problem is always harded when more
   than 2 people talk to each other - message interleaving is primarily why
   distributed systems are hard!
   - Related to the previous idea, the protocol design with just a single
   client talking to the server is *easier*. Also, only a single connection
   is established per client to the server, keeping it easier to manage
   connections.
   - From my impression and initial ideas on my mind, it looks like the UI
   app merely communicates control information to the daemon. Trivially it can
   just send the commands to the daemon and quit with an ack (a dumb UI
   implementation). Even otherwise, file transfers are not required as its on
   the same machine. Since the daemon would anyway have methods/modules to
   handle each user operation, this step is merely exposing this interface to
   the UI app.
   - I am planning to write an interface over Twisted python so that a
   message and its related handler can be registered with this interface. The
   message content is simply the arguments to this method. This would mean that
   its pretty easy to encode control messages. And the interface would handle
   all the ugly network communication, failure, (de)serialization, etc.

Eg:
*ClientUI* - send(ForceSync(filename)) # Implicitly sent to the daemon. *
ForceSync* is a message with filename as argument.
*Daemon* - def ForceSync(filename):
                 ...
(More details in a separate blueprint)


On Wed, Aug 4, 2010 at 3:13 PM, krishnan_p <krishnan.parthasarathi@xxxxxxxxx
> wrote:

> You are now subscribed to the blueprint client-side-architecture -
> Client side architecture.
>
> --
> https://blueprints.launchpad.net/acmeattic/+spec/client-side-architecture
>
> _______________________________________________
> Mailing list: https://launchpad.net/~acmeattic-devel<https://launchpad.net/%7Eacmeattic-devel>
> Post to     : acmeattic-devel@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~acmeattic-devel<https://launchpad.net/%7Eacmeattic-devel>
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Karthik