External File Management
Synapse supports upload/retrieval to file storage owned by users. An example is that of a private SFTP server.
Project Settings
Upload Destination on File Containers (Projects, Folders)
Synapse will generate a suggested file hierarchy into which the client uploads content. The client is responsible for generating missing folders.
Conventions for external URLs
Conventions for storing crendentials
(Cross reference to C-4 page)
Proposed Services Revision
(from Marcel's email of 11/17)
The current sequence for uploading a file goes like this:
Ask server for upload destinations for a synapse container
Get 1 or more upload destinations, of either S3 or external (SFTP)
Either let user choose, or upload to first default option
Upload to external file handle or ask for signed S3 url (using the upload destination)
This has a couple of problems, the most problematic one is that it doesn't handle the case where the R or Python client downloads a file, modifies it and then reuploads it again. We want the upload to got to the same destination, but if there is more than one option, that doesn't quite work.
Proposed solution (backwards compatible with the about-to-be released clients):
API
1) Add an API that gives a list of possible upload locations by ID and label for a given synapse container:
UploadDestinationLocation {
String uploadId;
String label;
}
UploadDestinationLocation[] getUploadDestinationLocations(String parentId);
2) Add an API that gives a single specific upload destination by uploadId (parentId is redundant, but used for extra check against the valid uploadIds):
UploadDestination getUploadDestination(String parentId, String uploadId)
Object Model
Add uploadId as a new optional field to an ExternalFileHandle (perhaps S3FileHandle has this field too).
Note: Need ExternallyManagedFileHandle to distinguish from non-managed ExternalFileHandle
Sequence
For uploading a new file:
Get upload destination locations for a synapse container
Have the user choose if more than one
For each new file:
Get upload destination for container and chosen upload Id
Upload to external file handle or ask for signed S3 url (using the upload destination)
Create new file handle
For modifying a file
Download file using file handle id
modify
Get upload destination for container and previous file handle id
Upload to external file handle or ask for signed S3 url (using the upload destination)
Create new file handle
Discussion about storing authentication details in configFile
> It would already be stored in the .ssh directory or the ssh-agent daemon.
Yes. As far as I can tell there isn't a standard for mapping a host address into the local file name for the SSH private key (.pem file). Perhaps our config file would provide this mapping somehow.
> The proposal would break this convention
Do you mean because your config file parser uses ":" as a separator? I thought .ini files used "=", but I'm ok if you want to avoid colons. Regarding your idea of naming sections after hosts: It seems unconventional (I think sections are generally a set of established headings, like "authentication") but I don't see why it wouldn't work, and it _does_ avoid the awkward alternative of having 3 pieces of information (host, key, value) on each line meant for just 2 pcs (key, value). One refinement is to include the protocol. (I can imagine someone supporting multiple protocols on the same server, messing up our approach). So the section header in your example would be:
[sftp://ec2-54-212-85-156.us-west-2.compute.amazonaws.com]
Bruce
On Mon, Nov 3, 2014 at 12:20 PM, Larsson Omberg <larsson.omberg@sagebase.org> wrote: