You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Extracts a TileSource interface to represent an abstract "source" for HiGlass's DataFetcher. The DataFetcher does a lot of processing of the values returned from the server, so it's challenging to just implement a different source that is not a webserver (e.g., a websocket). I think there is a lot more logic that could be reused to optimize requests, but this seems sufficient for the time being.
Why is it necessary?
This let's us connect DataFetcher to non-HTTP (i.e., non fetch-based) data sources.
Fixes #___
Checklist
Set proper GitHub labels (e.g. v1.6+, ignore if you don't know)
Unit tests added or updated
Documentation added or updated
Example(s) added or updated
Update schema.json if there are changes to the viewconf JSON structure format
Screenshot for visual changes (e.g. new tracks or UI changes)
Where jupyterTileSource uses Jupyter comms (websocket) to send/receive data, rather than fetch (HTTP-requests). We could even experiment with sending binary data over a protocol like this in the future (rather than base64 encoding dense tiles).
Tbh i don't really know what registerTileset is or does.... I've never implemented in higlass-python or server side implementations of higlass tile sources.
registerTileset was a semi-half-baked way of fetching tilesets that were not on the server. The idea was that the client would call the register_tileset endpoint with a url, the server would return a uuid that the client could use to fetch tiles. It would be as if the client was fetching directly from the url without implementing the http-based tile fetching code.
I think 4DN was using it. Might be possible to deprecate.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Extracts a
TileSourceinterface to represent an abstract "source" for HiGlass'sDataFetcher. TheDataFetcherdoes a lot of processing of the values returned from the server, so it's challenging to just implement a different source that is not a webserver (e.g., a websocket). I think there is a lot more logic that could be reused to optimize requests, but this seems sufficient for the time being.This let's us connect
DataFetcherto non-HTTP (i.e., nonfetch-based) data sources.Fixes #___
Checklist