acmeattic-devel team mailing list archive

[Aditya Manthramurthy <aditya.mmy@xxxxxxxxx>]

-----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-----