Need a list of protocols understood by cfstore and this needs to be a controlled vocabulary for "location types"

[bnlawrence]

Consider this use case:

Collection C1 has file F1 (from location L1)

We want to move F1 to a collection C2 on location L2.

To do this, we will invoke something to do the moving. That means we have to work out what protocol to use. That's obviously not a property of the file itself, but of the location on which the file exists. That means we need a relationship between a "location type and an available protocol". (It may of course be possible that there are multiple protocols available for any one location type (e.g. GridFTP, BBFTP, SCP) for Posix.

The obvious location types are file:/// (for posix) and S3:/// and ET:/// ...

We could hard-code those, or we could put them in a table. My sense is we should hardcode the types, and put them in as a location type.

[bnlawrence]

@davidhassell, @georgeoobrienNCAS - It'd be good to talk about this use case on Friday!

[bnlawrence]

Worth also pointing out that the protocol may depend on both ends of the move, and so the protocol cannot itself be a function of a location (singular).

[bnlawrence]

And that different individuals and bilaterals may use different protocols to talk to a location, so it may be a case of having a list of available protocols for a location ... but an individual user may have only a selection of those available to her for any given location. Need to consider how this impacts on the URIs we want to have in CFA files.

[bnlawrence]

(Tell everyone how the database diagram gets updated when I change the schema ... #31)

[bnlawrence]

Discussion today:

• "location type" should be a property of the location (we'll need an enum for that).
• protocol choice will need to use a lookup table for type at location L1 and location L2, where multiple protocols may be available, and there might or might not be a default (which might or might not be under user control).
• This will impact ticket #29

[bnlawrence]

I have added protocols as a completely empty table for now (see 18694c2) , so users can associate protocols such as magic to storage locations. We will put the "controlled" nature into the code, so as to avoid needing database updates if the enum changes. Code "controlling" still to come.

[bnlawrence]

(There is a branch with this name where this started, but b-metadata work got inserted in that branch by mistake. That's ready to push back to main now, so we may need to revisit this from a new branch from main.)