Non-X-prize web functionality?

[lynaghk]

I took a look through the functionality in bcbio.variation/src/bcbio/variation/web/ and it looks to me like most of it is X-prize related. Since the VCF analysis is separate, my intuition is to just put together a standalone server that uses bcbio and clj-genomespace as libraries rather than try to merge the repos right now. This might be a bit more work upfront, but I'm happy to do it to keep things from getting too monolithic. (Once we have a standalone working VCF analysis tool we could put it in bcbio---mainly I just don't think it makes sense to share any of the existing web code because bcbio is mainly noir+hiccup+X-prize while VCF is haml+sass based.) What parts of the bcbio web interface should we (Keming) work on porting over? I know we'll need the GenomeSpace login bits so that folks can access their files. Anything else?

As a sidenote, during this process I'll look into putting static resources (e.g., Twitter Bootstrap and Chosen) into upstream JARs so we can handle them as much as possible through Maven rather than git.

[chapmanb]

Kevin; Would it help if I refactored anything? I'm happy to make this more general so it's flexible long term.

The main things we could reuse from the current codebase are:

• GenomeSpace + sessions for logged in users
• Global web configuration input, via a little YAML file. This helps clean up the API, removing the need to point directly to reference FASTA files and specify directories.

Everything else is xprize specific, but I could refactor to make more general. Your choice since I want to make it as easy as possible for you, but let me know if it's easier for me to generalize here.

[lynaghk]

• We'll have a better idea of what (if anything) in bcbio needs to be refactored once we get a standalone VCF interface.

Questions:

• Is it still correct to assume that everyone using VCF will have a GenomeSpace login? If so, we can just block everything off behind a session check.
• Working dir is fine to keep in the config, but won't users want to choose the reference genome for VCF stuff? That seems like it should be another input field (against maybe some common genomes + extras on the user's genomespace), no?

[chapmanb]

Kevin;

• Yes, we'll require GenomeSpace for login and file management, so that's a safe assumption.
• Generalizing the reference genome is definitely something I'd like to do long term, ideally integrating with GenomeSpace support for metadata on files. Short term, dealing with human data and having a fixed genome works fine.

[lynaghk]

Awesome. Thanks Brad.