2 Switch from github style markdown to SE style markdown. line feed to engage the bullet points.
source | link

Imagine a client-server app that lets user upload images/documents etc. to server and then lets users who have access, retrieve and view them later on their respective mobile devices.

So the flow is something like this:

  • Creator (C) creates a message with n number of attachments.
  • C uploads the files and message to server via REST API.
  • Recipients R1, R2... Rn get notified about new content
  • R1, R2, and other go in on their own times and fetch the message and attachments.
  • Once downloaded, the mobile app doesn't request server the next time any of the recipients tries to view the attachments, it uses locally cached data.

Now the creator C already has the files (since it created them) and need not download them again. So when it gets a response from server like:

{
  messageId: 123,
  attachments : [ { id: a1, ...}, {id: a2, ...}, {id: a3, ...} ]
}
{
  messageId: 123,
  attachments : [ { id: a1, ...}, {id: a2, ...}, {id: a3, ...} ]
}

However, it doesn't know which attachment is what (i.e. which one is a1 and which one is a2 and so on).

It just knows that message #123 has 3 attachments.

What would be a good way to figure this out? There are 2 approaches that come to my mind:

Approach #1: use file hash - Calculate file hash (MD5 or SHA) and use that as a key on the mobile app. - Server does the same and returns the hash as identifier instead of a generated id.

  • Calculate file hash (MD5 or SHA) and use that as a key on the mobile app.
  • Server does the same and returns the hash as identifier instead of a generated id.

Pros:
- No extra metadata is needed for sync 

  • No extra metadata is needed for sync

Cons:
- Probably error prone - hash may not match due to OS or hash implementation differences - Hashing will be slow for big files 

  • Probably error prone - hash may not match due to OS or hash implementation differences
  • Hashing will be slow for big files

Approach #2: use a key
- App generates an UUID and sends it to server as an identifier. - Server stores it and returns the key with the response for syncing. 

  • App generates an UUID and sends it to server as an identifier.
  • Server stores it and returns the key with the response for syncing.

Pros
- Hash related errors are eliminated - Hashing speed is not a concern since UUID generation is pretty quick and deterministic. 

  • Hash related errors are eliminated
  • Hashing speed is not a concern since UUID generation is pretty quick and deterministic.

Cons - And extra key is passed between app/server which has no other purpose.

  • And extra key is passed between app/server which has no other purpose.

Which one of these is preferable? Or maybe there is a 3rd option?

Imagine a client-server app that lets user upload images/documents etc. to server and then lets users who have access, retrieve and view them later on their respective mobile devices.

So the flow is something like this:

  • Creator (C) creates a message with n number of attachments.
  • C uploads the files and message to server via REST API.
  • Recipients R1, R2... Rn get notified about new content
  • R1, R2, and other go in on their own times and fetch the message and attachments.
  • Once downloaded, the mobile app doesn't request server the next time any of the recipients tries to view the attachments, it uses locally cached data.

Now the creator C already has the files (since it created them) and need not download them again. So when it gets a response from server like:

{
  messageId: 123,
  attachments : [ { id: a1, ...}, {id: a2, ...}, {id: a3, ...} ]
}

However, it doesn't know which attachment is what (i.e. which one is a1 and which one is a2 and so on).

It just knows that message #123 has 3 attachments.

What would be a good way to figure this out? There are 2 approaches that come to my mind:

Approach #1: use file hash - Calculate file hash (MD5 or SHA) and use that as a key on the mobile app. - Server does the same and returns the hash as identifier instead of a generated id.

Pros:
- No extra metadata is needed for sync

Cons:
- Probably error prone - hash may not match due to OS or hash implementation differences - Hashing will be slow for big files

Approach #2: use a key
- App generates an UUID and sends it to server as an identifier. - Server stores it and returns the key with the response for syncing.

Pros
- Hash related errors are eliminated - Hashing speed is not a concern since UUID generation is pretty quick and deterministic.

Cons - And extra key is passed between app/server which has no other purpose.

Which one of these is preferable? Or maybe there is a 3rd option?

Imagine a client-server app that lets user upload images/documents etc. to server and then lets users who have access, retrieve and view them later on their respective mobile devices.

So the flow is something like this:

  • Creator (C) creates a message with n number of attachments.
  • C uploads the files and message to server via REST API.
  • Recipients R1, R2... Rn get notified about new content
  • R1, R2, and other go in on their own times and fetch the message and attachments.
  • Once downloaded, the mobile app doesn't request server the next time any of the recipients tries to view the attachments, it uses locally cached data.

Now the creator C already has the files (since it created them) and need not download them again. So when it gets a response from server like:

{
  messageId: 123,
  attachments : [ { id: a1, ...}, {id: a2, ...}, {id: a3, ...} ]
}

However, it doesn't know which attachment is what (i.e. which one is a1 and which one is a2 and so on).

It just knows that message #123 has 3 attachments.

What would be a good way to figure this out? There are 2 approaches that come to my mind:

Approach #1: use file hash

  • Calculate file hash (MD5 or SHA) and use that as a key on the mobile app.
  • Server does the same and returns the hash as identifier instead of a generated id.

Pros: 

  • No extra metadata is needed for sync

Cons: 

  • Probably error prone - hash may not match due to OS or hash implementation differences
  • Hashing will be slow for big files

Approach #2: use a key 

  • App generates an UUID and sends it to server as an identifier.
  • Server stores it and returns the key with the response for syncing.

Pros 

  • Hash related errors are eliminated
  • Hashing speed is not a concern since UUID generation is pretty quick and deterministic.

Cons

  • And extra key is passed between app/server which has no other purpose.

Which one of these is preferable? Or maybe there is a 3rd option?

1
source | link

Relying on file hash for data synchronisation across mobile and server

Imagine a client-server app that lets user upload images/documents etc. to server and then lets users who have access, retrieve and view them later on their respective mobile devices.

So the flow is something like this:

  • Creator (C) creates a message with n number of attachments.
  • C uploads the files and message to server via REST API.
  • Recipients R1, R2... Rn get notified about new content
  • R1, R2, and other go in on their own times and fetch the message and attachments.
  • Once downloaded, the mobile app doesn't request server the next time any of the recipients tries to view the attachments, it uses locally cached data.

Now the creator C already has the files (since it created them) and need not download them again. So when it gets a response from server like:

{
  messageId: 123,
  attachments : [ { id: a1, ...}, {id: a2, ...}, {id: a3, ...} ]
}

However, it doesn't know which attachment is what (i.e. which one is a1 and which one is a2 and so on).

It just knows that message #123 has 3 attachments.

What would be a good way to figure this out? There are 2 approaches that come to my mind:

Approach #1: use file hash - Calculate file hash (MD5 or SHA) and use that as a key on the mobile app. - Server does the same and returns the hash as identifier instead of a generated id.

Pros:
- No extra metadata is needed for sync

Cons:
- Probably error prone - hash may not match due to OS or hash implementation differences - Hashing will be slow for big files

Approach #2: use a key
- App generates an UUID and sends it to server as an identifier. - Server stores it and returns the key with the response for syncing.

Pros
- Hash related errors are eliminated - Hashing speed is not a concern since UUID generation is pretty quick and deterministic.

Cons - And extra key is passed between app/server which has no other purpose.

Which one of these is preferable? Or maybe there is a 3rd option?