Interviewer icon indicating copy to clipboard operation
Interviewer copied to clipboard

Async loading of remote assets

Open jthrilly opened this issue 6 years ago • 4 comments

As a final stage of remote asset implementation, we should support asynchronous loading of remote assets (primarily external data).

In Architect the user would be able to add a new asset or type "remote" (or similar). They would be able to construct a URL that would include templating for interview variable values (probably also a URL constructor worker that passes in the whole session/network model) like this: https://myuniversity.edu./myproject/?interviewID={egoID}

In Network Canvas we want to try to use new React features (suspense - mid 2019, and possibly concurrent mode - q2 2019) to implement this nicely. That means showing a spinner for loading data, and continuing to render everything else, and handling error states gracefully.

jthrilly avatar Jan 22 '19 12:01 jthrilly

For the Architect side of this I suggest we mirror the UI for importing dialogs in Network Canvas:

url-asset

wwqrd avatar Apr 22 '19 16:04 wwqrd

Few questions on that proposal:

  • Does that mean that the type is still being set by the pseudo mimetype system for the asset chooser? If so, good. I just wanted to make sure that you could, for example, have a remote asset that was a video and not just a network
  • Part of the specification for the network portion of this is that there is a template system to inject interview data into the request (either via query string, or POST or whatever). We can simplify this to being able to pass an attribute from ego, for now. That might mean this needs a more complicated and dedicated UI.
  • Another idea was to potentially use server as an endpoint for this data, and have corresponding functionality there that let you expose data, say from previous interviews.

Given the complexity of points two and three, and the lack of the React features to implement this in NC, I think we should postpone this feature.

jthrilly avatar Apr 23 '19 09:04 jthrilly

I hadn't considered types actually, given the nature of urls not neccessarily having extensions, we may be best to do some detection when we validate the URL, something like:

  1. is an image/video/audio?
  2. default to "network"

wwqrd avatar Apr 23 '19 09:04 wwqrd

I hadn't considered types actually, given the nature of urls not neccessarily having extensions, we may be best to do some detection when we validate the URL, something like:

  1. is an image/video/audio?
  2. default to "network"

I would prefer to make it explicit. Detection might be hard, because it wouldn't work for server generated resources that depend on live interview data.

jthrilly avatar Apr 23 '19 13:04 jthrilly