DeepDiver1975/dav

zip endpoint

Opened this issue · 5 comments

DeepDiver1975 commented

There should be an endpoint which allows creating of zips.
Root url: /dav//zip/

  1. send POST against root url - the POST body contains a list of files and folders to be added
  2. server locks them all
  3. the response holds a unique url to the archive like /dav//xxxx-xxxx-xxxx.zip
  4. client send GET against the given url - server starts to stream the content
  5. once client finishes a DELETE is send against the archive url - all files and folder will be unlocked

As an alternative to the .zip extension a .tar extension should be supported

DeepDiver1975 commented

Or we follow the approach of the uploads collection:

  1. MKCOL /dav/zip/$user/zip/12345
  2. PUT /dav/zip/$user/zip/12345/files.json
  3. GET /dav/zip/$user/zip/12345/archive.zip or /dav/zip/$user/zip/12345/archive.tar
  4. DELETE /dav/zip/$user/zip/12345
dragotin commented

Which problem do we solve here? Is it bundling for download? Sounds great.

Questions:

  • What happens if a file on the server vanishes between upload of the list.json and download of the zip?
  • Can we add requested ETags to the list.json and not add the files to the zip if the server can not get the requested ETag?
  • We have to care for server load so much. Compression is expensive so why do that at all, given that most files are already compressed as we know? We can just tar them together, without compressing.
  • If the server is smart, it could have a list of mimetypes where it makes sense to compress and others not. So it could simply create a tar with files which are compressed and other that are not. The client destinguishes by the extension. Example: susi.jpg is not compressed because jpeg already is, but loveletter_to_susi.txt is because it is text. The client gets susi.jpg and loveletter_to_susi.txt.zip in the tar.
  • The required DELETE at the end is asking for trouble. If the client passes away before the DELETE or is a dumb guy and simply does not do it, these dirs pile up on the server. Can we avoid it?

Otherwise nice. We should have something similar for upload.

PVince81 commented

We don't compress, zip or tar is only a way of bundling files.
There are two use cases:

  • download a single folder as zip
  • download a list of selected files a zip (as selected in the UI)
    Now thinking of it, if we can bundle several files this way the desktop client could even use that for batch download...
DeepDiver1975 commented

If we want to give the client the capability to download multiple files in one cycle we might want to follow CalDAV which defines a multi get report

https://tools.ietf.org/html/rfc4791#section-7.9