-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This mail is mainly about the locking problem we have been discussing.
The need for a separate daemon and UI processes on the client: 1) The commonest use-case for AA: a user wants backup of certain files, like the code for her project, and this folder is being updated by her often. She is not concerned with sharing, etc. All she should need to do is configure the project sources folder to be backed up on acmeattic and continue working. The daemon program aaclientagent, would simply run in the background, periodically backing up her data, transparently to her. 2) Occasionally she may want to administer her attic to get rid of old files perhaps. To do this, she turns on the UI application and does what she needs to. 3) Other users may want to share their data. This can also be accomplished with the UI app. This makes a good case for having separate processes, because the daemon's function is limited, but is commonly used. The client app should also be able to make explicit transfers with the server, so that the user can interactively manage her data. For example, there may be a folder in the server that is not present on her local machine (say it was backed up from a different client). To pull this data to her client, she fires of such an instruction from the UI app, which could interactively show her the progress of the transfer, etc. This makes a compelling case for why the client UI app should also be able to make transfers with the server as well. It can be argued that the UI app can accomplish this by talking to the daemon, but really that's a lot pain, especially if the aaclientlib makes available an API to talk to the server. Now, we come to the locking problem. It should be clear why there is a race. The race is between the aaclientcli and aaclientagent processes. I could not understand Bharath's resolution to the problem using a data structure. The lock only needs to control one resource - who will make the transfer with the server - UI app or daemon, or we lock who has access to the tranfer calls in aaclientlib. Clearly, either the lock has to be provided by an OS resource (as different processes need to request it) or by some other way. I am not sure what facilities are available for locking provided by the OS - some research is needed here. But one way which will work on all platforms is the lock file based method: http://en.wikipedia.org/wiki/File_locking#Lock_files Using lock files is the oldest way to achieve serialization, as this was the first provably foolproof method known in early unixes before further research came up in serialization algos. It is simple enough that it can be done on any OS. Using IPC can solve the problem too, but consider that the amount of code to achieve this would be non-trivial - we need to send messages to the daemon that ask it do various things, and this requires a message format; a message format means that we need to write code to compose the message as well as to parse and interpret it at the other end. OTOH, locking simply requires about 10 lines of code in aaclientlib to attempt to create the lock and then attempt the transfer. Hope that clears things up. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJMZR3/AAoJEJp+wO5X65iGe6kQAIKTvkD2OGBtj2uppLmMAsih k2FJVjOGY61A6/VS0TAScdh5AgELqjn0KPcWtJZxtCU69z18OJp2Sm3U+/DRHtme biXdpuEHW4fwac6NXkqaqEtOwo85a17EYrTkdukb+p+LN8N1Ej5j/zJ5UDw5HZdj ocpoaoC5KdLYp4oFBPnDSdKOdR3Ceay73LMNIs6y3sPohwVkRa+LZtSI5AxzBjEo VJh39rHHaV3dafufm/mjBbummOayTr2TdgxgfNiodRSYukUjuY0v6CTPC6njTUJn Z7X8YmvuNEAF2vg9l0DMLmOzDADdvTSJJZQu67fGCVbdD9qIhUU86ZpjbDB2inu1 k0Q+M3e5UrHHAXwJxJ5gxS5k43RS4DW0KY6muF3vf7IHg92uQfmSF+jrvwBUt2e0 m5v4ARogl8WURfJBAmAerDnGMihj3RgFIONzSCEcsIvdaXk8eVokKcq/J04QNpEc 86GCqiEe3N5k4xFSACiJwBVDulJcsL0fZv8wEB4WNOjvgM8/fM76laOSqpy1saUi d6Hbg3IRl8VCjRzkr6OkJ5NskDxVYAwFhT6qcygqhwI8EOAFkISKEVKmMBdfCNTq MLiwD1DmKGLKbDKRBU/O2gPJWwVDivANYmDaR7wLV0ErLEtni2o1JNEmsqIPy/jv cXOCw5yS0x+lN4nz5oMu =v8kK -----END PGP SIGNATURE----- _______________________________________________ Mailing list: https://launchpad.net/~acmeattic-devel Post to : [email protected] Unsubscribe : https://launchpad.net/~acmeattic-devel More help : https://help.launchpad.net/ListHelp
