Gestire l'upload di file di grandi dimensioni

[gvaldambrini]

L'upload del file deve essere fatto usando le solite route (POST /files/ o PUT /files/), con l'aggiunta di un nuovo parametro offset che indicherà il byte di partenza del pezzo inviato. Il server dovrà creare un file temporaneo associato sia all'utente che al file in upload, considerando l'upload a pezzi completato quando l'md5 del file temporaneo corrisponderà con quello inviato dal client. In quel caso il file diventerà un file normale a tutti gli effetti eventualmente sovrascrivendo un file nello stesso path (nel caso della PUT).

Il server dovrà anche:

• [x] memorizzare l'md5 del file in upload, in questo modo se il client invierà un file con lo stesso path e nuovo md5 il server potrà eliminare il file temporaneo rimpiazzandolo con il nuovo.
• [x] avere un timeout oltre il quale il file temporaneo sarà considerato non più valido e ogni richiesta ulteriore verrà riposta con l'opportuno errore (408).
• [x] gestire con un opportuno errore il caso in cui la prima richiesta abbia offset != 0 e quello in cui, in un upload già in corso, offset != len(file temporaneo).
• [x] ritornare 200 se l'upload di un chuck ha avuto successo, 201 se ha completato l'upload del file.

Il client dovrà:

• [x] decidere se inviare il file in un'unica soluzione o in più parti a seconda della dimensione del file (configurabile)
• [ ] gestire in modo opportuno gli errori del server e interrompere e ripartire con un upload a pezzi nel caso in cui un file di grandi dimensioni sia modificato.

[eatsjobs]

Il server è praticamente pronto rimanere da concludere con il resto dei test. La chiamata che parte dal demone invece ha un problema: è bloccante. Possibili soluzioni: 1) thread 2) una classe che tenga traccia degli upload in corso con un metodo advance_all() chiamato dal demone ad ogni ciclo. Con Gendo pensavamo alla seconda.