implement data hub UI

[rbuels]

make a drawer widget that:

• lists data hubs that we currently know about, with a check box showing whether they are "connected"
• has a UI to add a data hub
• persists the list of hubs in local storage
• when a data hub is connected, adds its assemblies and tracks to the configuration (root.configuration.tracks, etc) so that the tracks are available in the track selector

[garrettjstevens]

May as well start with supporting UCSC Track/Assembly hubs since they're so well-defined. Once the UI is in place we can expand to other types from there.

[garrettjstevens]

Working on a "stepper" that steps through the process of importing a data hub:

[garrettjstevens]

I've got a UI for choosing either a hub from the Track Hub Registry or from a user-provided URL (includes parsing the hub.txt and genomes.txt of the user-provided URL to select a genome/assebly). Now need a parser for the trackDb.txt files. Will continue here once that is done (#45).

[rbuels]

Dude this is awesome.

…

On Tue, Dec 18, 2018 at 10:13 AM Garrett Stevens ***@***.***> wrote: I've got a UI for choosing either a hub from the Track Hub Registry or from a user-provided URL (includes parsing the hub.txt and genomes.txt of the user-provided URL to select a genome/assebly). Now need a parser for the trackDb.txt files. Will continue here once that is done (#45 <#45>). [image: image] <https://user-images.githubusercontent.com/25592344/50162966-7b230080-02ad-11e9-8cc8-e32202e37626.png> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#31 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEgFTclKZkyssPM8RP44vLfGbvwOFt1ks5u6QYCgaJpZM4ZI-l0> .

[garrettjstevens]

Framework now in place to pull in track info from a trackDb. So far using it to pull in all track names to confirmation dialog.

[garrettjstevens]

Been testing on a large track hub (http://ftp.ebi.ac.uk/pub/databases/ensembl/encode/integration_data_jan2011/hg19/trackDb.txt) and it's a bit slow (~23s) to pull in all 1763 tracks. Might be memory-related? Might be unavoidable with that many tracks, though. Could put some of the processing in a webworker, and have the webworker return a snapshot to be attached to the root MST model.

[rbuels]

Yes actually I would recommend doing it in a worker. Probably just use the same render worker, since we are unlikely to need to render at the same time

…

On Mon, Dec 31, 2018 at 5:39 PM Garrett Stevens ***@***.***> wrote: Been testing on a large track hub ( http://ftp.ebi.ac.uk/pub/databases/ensembl/encode/integration_data_jan2011/hg19/trackDb.txt) and it's a bit slow (~23s) to pull in all 1763 tracks. Might be memory-related? Might be unavoidable with that many tracks, though. Could put some of the processing in a webworker, and have the webworker return a snapshot to be attached to the root MST model. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#31 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEgFYNYI4IkBNVjtjF9-E3n2MjGBuYGks5u-pIYgaJpZM4ZI-l0> .

[garrettjstevens]

@rbuels, @cmdcolin, I've been thinking about what it means to be "connected" to a data hub, and I'm curious to hear if you have any thoughts.

"Connecting" to a hub seems to imply that at some interval JBrowse will check the hub for updates. What kind of interval should that be? Minutes, days?

Also, what if someone connected to a hub and then edited the config for one of the hub tracks (for example the description)? You'd want that config to persist, but you'd have to keep track of those changes to keep them from getting overridden when the hub updated. And what if the user and the hub both change the same thing? Now there's a "merge conflict."

We could get around this, though, if we "imported" from data hubs instead of "connected" to them, meaning that it was a one-time action and any local changes would get overridden (with a warning) by any future imports.

[cmdcolin]

same sort of issue was basically coming up here GMOD/jbrowse#1272 and can happen in basically any tracklist scenario if you want user customizations to persist

I'd say override with warning is basically fine though. I also think that an indication that this track is not using the default config is helpful

[garrettjstevens]

Related to importing and overwriting tracks, currently JB2 allows multiple identical tracks to be created. This is because each track gets an internal unique ID when created. That makes overwriting tracks tricky, since it means the track name (or any part of the config) isn't guaranteed to be unique. Do we want to enforce unique track names?

[garrettjstevens]

We now have a UI to add remote tracks from a Track Hub (#64). After #69 is done, we'll want to change this UI to add to the remote tracks instead of the normal tracks, but that can be a separate issue later.