acmeattic-devel team mailing list archive

[krishnan parthasarathi <krishnan.parthasarathi@xxxxxxxxx>]

After some deliberation on the design details we had come up so far, Aditya
and
me have thought of some modifications.

When we use reverse diffs to maintain older revisions of a file, the client
needs to upload the latest revision of the file along with latest reverse
diff
to the server, during updates. In a forward diff approach we would need to
send
only the latest diff. On the flipside when we setup the client for the first
time on a machine, we need to download the first revision and all the diffs.
This is not too bad since we need to do this only once for every new client.
So
our server app will store the first version of the file and all the diffs
upto
the latest revision.  To reduce the amount of download a new client
initialisation requires, the server could compute the total download size
(of
first revision of file and all diffs) and on reaching a threshold value can
ask
client to send the 'current' version of the entire file in place of a diff.
By
this approach, a new client only needs to download diffs upto the last
'fully'
present revision to recreate the latest revision of the file.

The line preserving diffs between encrypted revisions on the server side is
expensive on storage. Instead now the diffs will be between the unencrypted
revisions of the file and taken at the client side. On update, client
encrypts
the diff and sends it to the server.

In the event that a user loses his copy of the RSA key pair which he shares
with the server for encrypting his master key file, he must be able to
retrieve
it from the server using his password. For this we must devise a challenge
based authentication scheme like the one described in SpiderOak's articles.

Cheers,
Krishnan