Interviewer
Interviewer copied to clipboard
Async loading of remote assets
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.
For the Architect side of this I suggest we mirror the UI for importing dialogs in Network Canvas:

Few questions on that proposal:
- Does that mean that the
typeis 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.
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:
- is an image/video/audio?
- default to "network"
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:
- is an image/video/audio?
- 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.