Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Async loading of remote assets #847

Open
jthrilly opened this issue Jan 22, 2019 · 4 comments
Open

Async loading of remote assets #847

jthrilly opened this issue Jan 22, 2019 · 4 comments

Comments

@jthrilly
Copy link
Member

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.

@wwqrd
Copy link
Contributor

wwqrd commented Apr 22, 2019

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

url-asset

@jthrilly
Copy link
Member Author

jthrilly commented Apr 23, 2019

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 jthrilly removed the blocker label Apr 23, 2019
@jthrilly jthrilly modified the milestones: June - Beta 1, Beta-stretch Apr 23, 2019
@wwqrd
Copy link
Contributor

wwqrd commented Apr 23, 2019

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"

@jthrilly
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants