WiP: dump of thoughts on "services registry"

This is a draft to tune, not yet ready for any public issue/PR on how we could establish a registry of "registered services" to link to for any given file/directory/dandiset.

We will grow the collection of services we would like to "connect to"

• Metacell NWB Explorer Example Note: ATM needs redirected URLs, see https://github.com/MetaCell/nwb-explorer/issues/244
• jupyterhub
• binder instance (related: parametrization https://github.com/jupyterhub/binder/issues/175#issuecomment-549070163)
• https://github.com/dandi/dandiarchive/issues/68 - bioimagingsuite - for neuroimaging files and later possibly entire BIDS datasets dandisets (for a WiP sample, have a look at https://bioimagesuiteweb.github.io/alphaapp/dualviewer.html?repo=https://datasets.datalad.org/labs/haxby/attention)

So we should have a registry of external services which would be associated with particular type(s) of files or entire dandisets. So, I think it would be nice to establish some "standardized" way to list available services, which could allow in the future to expand the list with additional ones, may be even per particular user/lab.

I see an associative array (e.g. python/json/yaml dict) with name of external service: specification where specification is another dict with following keys to be defined

• endpoint: a template/format (e.g. Python format spec) to define url based on values we would provide for
  • url - url to the file/dandiset
  • name - the basename of the file/dandiset/directory
  • metadata - dictionary with all metadata -- might come handy, so why not?
• item: dandiset or file or directory, although I do not have yet a concrete use case for a directory
• filter (either of following): if defined should for a given item to decide if it is applicable. The most straight-forward filter could be regex (e.g. .*\.nwb) or extensions (e.g., nwb or tar.gz; single or a list), or may be mimetype (e.g. application/x-hdf)

More interesting case could be external services which would need more than one file/url to be provided, e.g. overlay tools of some kind (e.g., visualize spike sorted data along with raw data; MRI - activation map on top of anatomical see #68 which can do that), or just bundling multiple files (e.g., dunno, something like "publish to figshare" external service ;)) . There it would require defining

• items (list or dict) which would contain entries with item and filter.

So example would be something like

NWB Widgets (Binder):
  item: file
  extension: nwb
  endpoint: http://mybinder.org/v2/gh/dandi/services/master?urlpath=ipy/widgets.ipyn&paramurl={url}&title=Explore%20{name}
Bioimagesuite/Viewer:
  - item: file
    regex: .*\.nii(\.gz|)
    endpoint: https://bioimagesuiteweb.github.io/webapp/viewer.html?image={url}
  - item: directory
    endpoint: https://bioimagesuiteweb.github.io/webapp/viewer.html?repo={url}
Bioimagesuite/DualViewer:
  - item: file
    regex: .*\.nii(\.gz|)
    endpoint: https://bioimagesuiteweb.github.io/webapp/dualviewer.html?image={url}
  - item: directory
    endpoint: https://bioimagesuiteweb.github.io/webapp/dulviewer.html?repo={url}
MetaCell/NWBExplorer:
  item: file
  extension: nwb
  endpoint: http://nwbexplorer.opensourcebrain.org/nwbfile={url}

Note that in above, names provide different endpoints depending on the item (file or directory).

Related:

• what would be the URL we expose - dandi redirect or target (to s3): https://github.com/dandi/dandiarchive/issues/54