configuration for enabling DCM,RSAL, etc (external components)

[pameyer]

External components for non-http uploads, downloads, etc (DCM,RSAL) are disabled by default; in order to be usable there needs to be a way to turn them on.

For SBGrid v1.0, minimal functionality would be disabling native (http) uploads and downloads in favor of DCM/RSAL uploads and downloads.

Open questions:

• Installation-level or dataverse-level? dataverse-level is additional complexity that doesn't (yet) seem to get additional functionality
• Settings table, or elsewhere? Probably settings table
• One switch for both uploads and downloads, or one for each? Two switches (aka - one for each) seems like it's worth the minimal additional complexity.
• Binary configuration items (on/off switch), or lists (native/http,dcm/rsync+ssh, etc)? Additional implementation complexity and/or performance of lists vs binary hasn't been evaluated

[pameyer]

"elsewhere" other than settings table - possibly JVM options; possibly properties file.

"Don't document settings" (from PD - these settings won't be useful until dependent issues are implemented).

[pdurbin]

@scolapasta have we made a decision about how and where to persist whether a dataset is in "rsync" mode or "standard" mode? See #3347 where there's a proposed enum that contains three items:

• STANDARD
• RSYNC
• DROPBOX

In that code the "mechanisms" are persisted at the dataverse level as "RSYNC:STANDARD" for example: https://github.com/bmckinney/dataverse-canonical/blob/b280c34fcc231b41cf9e801aff992e3858c17775/src/main/java/edu/harvard/iq/dataverse/Dataverse.java#L724

If all of this is out of scope for this issue, which issue are we using to track this? @djbrooke has asked if we can close #3347 but we still have a need to express what mode a dataset is in.

[pameyer]

Current experimental protoype:

• Installation level configuration
• in setting table (not JVM options / properties file)
• two switches (one for uploads, one for downloads)
• Lists instead of binary on/off, support methods in edu.harvard.iq.dataverse.SettingsWrapper; absence of setting for handling upload/download treated as 'native only'; likely makes sense to move generic "do stuff with setting" list out of there but will defer that until discussion/code review.
• ugly POC UI exists, primarily for evaluating functionality (in other words, xhtml changes not for merging)
• makes sense to have tests on SettingsWrapper.allowNativeDownloads() , SettingsWrapper.allowNativeUploads(); currently unclear on how.

Additionally - ugly POC UI testing clarified that "disable native" will have non-UI implications (distinct from #3725).

[pameyer]

For reference, current experimental prototype https://github.com/IQSS/dataverse/tree/3724-extconf

[pameyer]

re "likely makes sense to move ..." - place to move to appears to be edu.harvard.iq.dataverse.util/SystemConfig