BioJS 3.0 working draft

[yochannah]

I've started drafting a spec here:

https://hackmd.io/j8y-Ht9_TP2yaDhYdUeIEQ# - please feel free to review, edit, discuss, etc.

It's not complete yet - I'll probably be working on this a little over the next few days.

[sarthak-sehgal]

Regarding BioJS 3.0 and the front-end idea for GSoC 2019: I tried looking at Dennis' code for building the visualisations but I was only able to get a vague idea so I'll have to brush up some stuff first. 😅 In my opinion, the transition to BioJS 3.0 and what idea we present for GSoC depends on what approach we choose for the visualisations - 1. Whether we want to continue using wzrd or 2. We want all the components to serve us an example or a build file at least or 3. We expect a student to work on Dennis' component builder So we can maybe discuss and reach a conclusion for this in the upcoming meet? An idea I had for GSoC: - Writing tests for the visualisations and maybe send an exception mail to the community or log the reports somewhere. This would enable us to maintain the quality of components being served and we could notify the author about the incompatibility. Regarding the offline compatibility, please correct me if I am wrong, do the packages require internet connection when GitHub repo is cloned and they are served locally?

…

On Thu, Jan 17, 2019 at 10:36 PM Yo Yehudi ***@***.***> wrote: I've started drafting a spec here: https://hackmd.io/j8y-Ht9_TP2yaDhYdUeIEQ# - please feel free to review, edit, discuss, etc. It's *not* complete yet - I'll probably be working on this a little over the next few days. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#55>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AbqNfsCzAMgwuTQiEQTNqabQQ6qdvd4Wks5vEK2hgaJpZM4aGV_-> .

[yochannah]

In my opinion, the transition to BioJS 3.0 and what idea we present for GSoC depends on what approach we choose for the visualisations - 1. Whether we want to continue using wzrd or 2. We want all the components to serve us an example or a build file at least or 3. We expect a student to work on Dennis' component builder So we can maybe discuss and reach a conclusion for this in the upcoming meet?

I strongly think 2 is a reasonable minimum - either having that build file in the package itself, or on a CDN somewhere ought to be mandatory. CDN might be better because it allows naive users to copy and paste their desired app into HTML, without having to download node, install dependencies, and find the compiled script!

There's still value in working on the component builder, as it'd be nice to support packages that aren't 3.0 compliant on a best effort basis.

An idea I had for GSoC: - Writing tests for the visualisations and maybe send an exception mail to the community or log the reports somewhere. This would enable us to maintain the quality of components being served and we could notify the author about the incompatibility.

I like this idea - maybe a status dashboard or something, with optional notifications?

Regarding the offline compatibility, please correct me if I am wrong, do the packages require internet connection when GitHub repo is cloned and they are served locally?

Yep, they'd have internet at some point, but imagine, say, the tools getting transported to somewhere rural on a USB stick. I don't think all tools need to be compliant, but it would be good to have a way to find tools that are, and encourage tools to be offline-friendly.