CMap Version 2 Design
The hopes and dreams for a new generation....
Up to CMap.
- No more "cmap_" table prefix
- Move to support only MySQL InnoDB tables to get proper foreign keys, not worry about implementing common db functions in Perl
- New, slimmer schema
- Eschew evidence table
- In the past, there was a canonical "feature_correspondence" table and the "f1->f2" correspondence was duplicated into a "correspondence_lookup" table where "f1->f2" and "f2->f1" in order to write simple SQL. The new version will remove the lookup table and simply have correspondences be repeated in the one table (making them essentially one-way).
- Map and feature types originally existed in the database but were moved into configuration files in past versions. They will be restored to there previous tables because any mismatch in configuration files and incoming data can easily cause data to be quietly ignored, creating many headaches for the author. Back in the db, code will be able to instantiate the needed types, and SQL will make cleanup of types easy.
- Steal the binning idea from Gbrowse to speed up feature retrieval, group features into chunks for display as sparklines
- All output to SVG, convert to other formats as needed
- Each "slot" holding maps in a comparative view will be generated and cached individually on server side; they will be assembled into a larger SVG container with an additional SVG to show the correspondence lines; changes to one slot will necessitate only changes to that image
- It will be possible to pregenerate all initial map views (e.g., whole chromosomes) for immediate viewing; other images can be labeled and cached as users create views, enabling re-use of images
- Circos to be used to generate circular views
- I've written to Dave Edwards and Chris Duran at the Univ. of Queensland (Australia) about including their 3-D Java desktop app as a server-side tool; no word back
- Investigate Google's O3D
- Also can investigate using GraphViz, gnuplot and PDL for other presentations
Write loaders for: