Open cmdcolin opened 3 years ago
Discussed with @elliothershberg, note that things like ideogram, gwas, etc all could certainly use more work and add new features so has some maintenance burden
All the ones listed are currently are just my personal repos
One related thing I'm wondering is:
Should we even consider moving some plugins from external to core?
The main one that comes to mind is https://github.com/cmdcolin/jbrowse-plugin-ucsc-api
In our discussion of improving data import (re-designing/extending the "Add track" workflows, new ways to add assemblies, etc.) I think it could be great to make this kind of plugin for ingesting UCSC a core part of the product. I feel like the absolute killer feature of UCSC is the amazing data available, not the viz.
ucsc-api is pretty cool, but sometimes (a) incorporating API based things into core can be difficult because API changes, for whatever reason, could happen and then we ship the built version of our code, and it is difficult to update (b) we also target the longtail of genomics where they might not be on UCSC and instead of targetting that longtail it could be that our "central jbrowse instance" has preloaded ucsc data e.g. for https://github.com/GMOD/jbrowse-components/issues/1870 but that needs a little fleshing out and (c) i have observed not ideal API responses and CORS error before and it may not be super well optimized to fetch all data from UCSC's API
so, it's tough and definitely worth considering even despite things like that, but it might be better to optimize our "central jbrowse instance" workflow and our ease-of-use to install things from plugin store so that people can install third party plugins easily
Possible candidates include
jbrowse-plugin-gwas jbrowse-plugin-biothings-api jbrowse-plugin-arc-renderer (not listed yet) jbrowse-plugin-biowasm (not listed yet) jbrowse-plugin-ideogram
It's kind of intangible just moving organizations, just whether we want to sort of "as a group" adopt these plugins