Skip to content
Snippets Groups Projects
Commit 5023df4a authored by edgrif's avatar edgrif
Browse files

fix up autumn/spring goals.

parent 47896c72
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
doc/Project_notes/Strategy_Autumn_2008.shtml
+ 359
− 23
View file @ 5023df4a
<HTML>
<!--#set var="banner" value="ZMap Strategy/Goals for Autumn 2008/Spring 2009"-->
<!--#include virtual="/perl/header"-->
<HEAD>
<TITLE>ZMap Strategy/Goals for Autumn 2008/Spring 2009</TITLE>
</HEAD>
<BODY>
<br />
<fieldset>
<legend>Overview</legend>
<p>The last year has been a slog of bug fixing, bug fixing, bug fixing. We need to make some
larger and more planned design changes.</p>
<H1>Overview</H1>
<p>We have been bug fixing and bug fixing but now we need to make some larger
changes again.
<H4>Plan for conferences</H4>
<p>
We should plan to present at one or all of these:</p>
</p>
<ul>
<li>April: BioCurators (Berlin)
<li>summer: ISMB/BOSC (???)
<li>Autumn: Genome Informatics (Cold Spring Harbour)
</ul>
<p>
Note that BOSC at least will mean that zmap needs to go on the external website, before we
do that ZMap should at least read GFFv3 files and from DAS sources.
</p>
</fieldset>
<br />
<fieldset>
<legend>Autumn Goals</legend>
<h4>Styles in place - End of Oct</h4>
<p>
Styles is required for a number of other changes/fixes we need to make. It's essential
to finishing off ZMaps independence from acedb.
</p>
<h4>User Config in place - End of Oct</h4>
<p>
Users cannot save at the moment so we must do this.
</p>
<H1>Goals</H1>
<h4>Improving Testing - End of Oct</h4>
<H3>Improving Testing</H3>
<p>
We only do adhoc testing and this must now change.
</p>
<p>
ZMap could be tested by adding code so that zmap would run off GFF and
styles files. This could be done in batch and commands sent to zmap from
Roys X Atoms/Properties interface tester. Zmap could also dump data so
allowing diff'ing of output files to catch changes in data positions/types etc.
The test system could run in the following way:
</p>
<ol>
<li><p>A test script will run zmap and associated test programs.</p>
<li><p>ZMap will read features and styles from files.</p>
<li><p>Roys xremote test program will read a file containing commands and send those
commands to zmap logging the commands and responses.</p>
<li><p>Some commands will result in zmap dumping data to files, these files will
be diff'd to detect differences.</p>
</ol>
<p>
The following pieces of code would be required to do this:
</p>
<ul>
<li><p>The GFF file reader code would need to be revamped.</p>
<li><p>The Styles file reader would need to be revamped.</p>
<li><p>The GFF dumper would need to be revamped.</p>
<li><p>We should add a complete context dumper (including styles).</p>
<li><p>The GFF file reader code would need to be revamped. (Ed)</p>
<li><p>The Styles file reader would need to be revamped. (Ed...see Roys .ini code)</p>
<li><p>The context dumper (including styles) would need to be revamped (we could add GFF output later).
(Roy)</p>
<li><p>Roys command program should be able to take a file containing a
list of commands and pass them over.</p>
<li><p>We should also diff the zmap log file.</p>
<li><p>We should diff the zmap log file.</p>
</ul>
<H4>Dynamic Loading</H4>
<ul>
<li><p>Load into mark region</p>
<li><p>change column config</p>
<li><p>sort out config file + style support</p>
</ul>
<H4>Build Script for mac</H4>
<p>Should finish this and pass it on to systems.
</p>
<H4>Supporting other data sources</H4>
<p>
Current status:
</p>
<table style="width:600px;" class="zebra" id="data_sources">
<caption align=top>Data Sources</caption>
<thead>
<tr>
<th>Format</th>
<th>Source</th>
<th>Status</th>
</tr>
</thead>
<tbody>
<tr>
<td>GFF v2</td>
<td>Acedb server</td>
<td><b>Supported</b></td>
</tr>
<tr>
<td>GFF v2</td>
<td>File</td>
<td>Used to work</td>
</tr>
<tr>
<td>GFF v3</td>
<td>Acedb server</td>
<td>40% written</td>
</tr>
<tr>
<td>GFF v3</td>
<td>File</td>
<td>not written</td>
</tr>
<tr>
<td>DAS v1</td>
<td>http server</td>
<td>40% written ?</td>
</tr>
<tr>
<td>DAS v2</td>
<td>http server</td>
<td>not written</td>
</tr>
<tr>
<td>Otter Pipeline</td>
<td>mySQL server</td>
<td>not written</td>
</tr>
<tr>
<td>Ensembl v??</td>
<td>http server</td>
<td>not written</td>
</tr>
</tbody>
</table>
<p>
Currently GFFv2 is all that we really support, Ensembl could be a good one for
getting zmap used more widely, Otterlace pipeline is more useful to us locally.
</p>
</fieldset>
<br />
<fieldset>
<legend>Spring Goals</legend>
<H4>Publish Zmap</H4>
<p>
Probably we need at least GFFv3 file reading support and maybe DASv1 as well.
</p>
<H4>Dynamic Load of Pipeline data</H4>
<p>
We need this to speed up initial loading of acedb database (we should give the annotator
the option of whether to load all data into the local acedb database or do it dynamically).
We need it to properly support really efficient dynamic loading and also to prove that
zmap can loading from many sources.
</p>
<H4>Publish Interclient Communication for annotation</H4>
<p>
The GAT 2008 produced as one of its actions a need to specify interclient conventions,
zmap is different from other annotation engines in that way and we should take advantage
of that and publish our interface before others do.
</p>
<H4>Blixem/dotter</H4>
<p>A constant request has been for better integration of blixem/dotter with zmap, neither
uses interclient communication currently so we have a clean sheet there. We should use the
Interclient comms from above for this purpose.
<H4>Heat Map</H4>
<p>We need a summary display like IGB to get over the large data volumes issue.
We'll need to talk with James about this since we will need precomputed data which
means he will have to add code. We'll need a styles property to signal that a data
source has this I think.</p>
<p>
I'm not sure we need the hierachy idea, need to think about that. Do users really
scroll like that....
</p>
<HR>
<H4>Feature dumping</H4>
<p>There have been several requests for this and it would fit in with our testing.
We should do GFFv3 dumping as our first option. I can copy the acedb code here
to some extent.</p>
</fieldset>
<br />
<fieldset style="width:600px;">
<legend>Background Goals</legend>
<H4>New bump modes/highlighting</H4>
<p>Some urgently needed here for filtering aligns in better ways and providing highlighting
that matches transcript stuff
</p>
<H4>Blixem/dotter</H4>
<p>Currently we just start these up fairly dumbly. Neither has any xremote stuff
so the world is our oyster there.
</p>
</fieldset>
<br />
<fieldset>
<legend>Other Goals</legend>
<H4>A New Canvas</H4>
<p>
The goocanvas (or something like it) would offer the following crucial advantages:
</p>
<ul>
<li><p>A proper MVC implementation which would save a lot of memory when splitting windows
and offer better interfacing and control of redrawing from our code.</p>
<li><p>Would handle issues to do with the X Windows maximum window size limit.</p>
<li><p>Has much better support to allow adding of new glyph types.</p>
</ul>
<p>
For now we should shelve plans to update the canvas because GTK has not decided which canvas
to support and it's pointless to swop canvas's only to find that GTK now supports a different one.
</p>
<H4>Multiple alignments</H4>
<p>no one is asking for this.</p>
<H4>Control, View, Window refactoring</H4>
<p>
Originally the main components of a single zmap window were:
</p>
<ul>
<li>ZMapControl: the toplevel window with all the controls
<li>ZMapWindow: the feature display window
</ul>
<p>
but then the requirement to have more than one context within a ZMapControl window came along
so ZMapViews had to be introduced:
</p>
<ul>
<li>ZMapControl: the toplevel window with all the controls
<li>ZMapView: an intermediate layer handling the data for one or more ZMapWindows
<li>ZMapWindow: the feature display window
</ul>
<p>
ZMapView has never really worked well from the windowing point of view, everything communication
between ZMapControl and ZMapWindow ends up passing through it. This is tedious to program and
therefore error prone and almost certainly bad design.
</p>
<p>
The really telling point here is that ZMapView has no GTK widgets of its own aside from the
xremote widget, even the navigator window is encapsulated into its own object.
</p>
<p>
Probably a better system would be something like:
</p>
<ol>
<li>A ZMapControl window is created.
<li>ZMapControl creates a ZMapView object and hooks up callbacks for <b>View</b> stuff only.
<li>ZMapControl creates a ZMapWindow (empty) and hooks up callbacks for <b>Window</b> stuff only.
<li>ZMapControl passes the ZMapView to ZMapWindow, this will end up with the window displaying the view.
</ol>
<p>
What's different here is that the ZMapWindow(s) communicate directly with ZMapControl and ZMapView
has callbacks directly to ZMapControl. ZMapControl will update the ZMapWindows when something happens
to ZMapView. Note that in this plan zmapView will not receive callbacks from ZMapWindow.
</p>
<p>
I think this can work but I haven't gone through all the communication between the layers to check.
It feels cleaner and simpler.
</p>
<H4>Splicing display</H4>
<p>Can we do an IGB like thing and just show exons ? Actually far from
simple for us to do.
</p>
<p>
Probably the best plan would be to let the user select a transcript and then open
a new window where each "block" is an exon (+ a surrounding bit). That way individual
exons could be bumped. We could filter the data from the existing context (would be a
useful function: get data in given gapped range).
</p>
</fieldset>
<br />
<fieldset id="travel">
<ADDRESS><a href="mailto:edgrif@sanger.ac.uk">Ed Griffiths &lt;edgrif@sanger.ac.uk&gt;</a></ADDRESS>
<!-- hhmts start -->
Last modified: Tue Oct 7 16:21:04 BST 2008
Last modified: Tue Oct 14 08:47:11 BST 2008
<!-- hhmts end -->
</BODY>
</HTML>
</fieldset>
<!--#include virtual="/perl/footer"-->
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment