meeting record.

doc/project/2006_01_06.meeting

+ZMap Meeting
+
+
+Date: 06.01.2006
+
+
+Present: Ed, Roy
+
+
+
+lace system:
+
+status - needs testing for robustness and speed...  **EG to install on his account and try it.
+
+problems -
+
+Currently 
+
+Actions - **Roy to arrange a meeting with James et al. to dicuss following issues:
+
+1) Does the lace system read any data from the acedb database at the end of the
+session or is the database effectively READONLY ? 
+
+2) Unique ids...can James supply these in the data from the database so we can read
+them directly. We already have a slot in our feature data struct for them. This unique
+id may be good to use in a separte hash of unique_ids -> canvas features which could
+unambiguously go from one to the other.
+
+3) Genefinder - can this be run from the perl code and then the results sent across
+to us as a Style + the data ? It makes for this to be done in the lace layer because
+gene finder is principally about interactive annotation.
+
+4) we have a performance problem with the g_dataset, to circumvent this can we reduce
+the number of homols being displayed ?
+
+5) Can we migrate quickly from the dual xace/zmap system to a zmap only system. **RS to check.
+
+6) discuss adding whole columns with James, e.g. genefinder data.
+
+
+
+XML-xremote mechanism:
+
+Currently we do not have the basic functions to add/modify/remove features to support
+this. We need this, and we may also need a function to get the server to parse in
+data. Can be tested via the feature editor. **EG to make sure this works.
+
+We need to review the operations in the XML-xremote interface, **RS to do this.
+
+We will need the xremote mechanism to dynanically add whole columns. This will involve
+operations to do at least:
+
+- adding the column name into our column list so it appears in the correct position
+in the columns.
+
+- adding the style for the column to our set of styles _before_ we are given the column
+itself.
+
+- adding a whole column with data.
+
+
+
+
+ZMap Display:
+
+- transcripts now display the CDS but not start/end not found. This data should be
+dumped in GFF and available.  **RS to check this out.
+
+- separate scale window...not done but not a priority.
+
+- 3-frame translation, not done  **RS to code this.
+
+- reverse complement, not done   **EG to investigate, will users be prepared to put up
+with the hit of refetching the data or should we fudge it locally. Check how acedb does
+this now, I think Simon changed it not to cache data so much.
+
+- DNA highlighting - EG thinks he may have broken it in moving the code for
+the DNA into ordinary feature group.  **RS to check.
+
+- mulitple feature types in a single column needs checking to see if it is still
+working. **EG to do this.
+
+- blixem needs to be checked to see it still works. **EG to do this.
+
+
+- methods and columns and things: we had a useful dicussion about these and came
+up with:
+
+	- we need to publish a list of "reservered" style/method names for
+	columns that are either derived dynamically or special in some way,
+	e.g. dna, genefinder output, 3-frame translation. The user can create
+	styles with these names and their style will be applied to these specific
+	datasets (if available, e.g. the dna may not be available). The user
+	cannot use these names for their own columns/data, they are reserved.
+
+
+In addition the rules concerning display will be tightened to be:
+
+- if any column is not in the columns list it will not be displayed.
+
+- if a column is in the columns list but there is no style for it, it will not be
+displayed.
+
+i.e. columns without styles will be removed from the columns list and will
+not be displayed.
+
+
+
+g_dataset problem:
+
+To recap: 
+
+the glib g_dataset code grinds almost to a halt while we are processing the GFF
+from the server. We've not been able to profile this well within our threaded
+environment sadly. What we do know is that it seems to spend a lot of time in
+a free routine so it maybe a problem with glibs chunk routines for allocating
+blocks of memory. It may also be, as Roy suggests, that its having to search
+longer and longer lists of blocks...
+
+solution is to write a small program that uses the GFF parser to read in a file,
+this should be simple, in a single threaded program and see where the problem is.
+
+A temporary solution is to try and reduce the enormous number of homols being
+displayed.
+
+
+
+Styles, Features and canvas item drawing....:
+
+this is an old chestnut...what decides how a feature is drawn ? Is it only
+the style ? Is it the feature type (e.g. allele etc.) ? In acedb the feature
+type was the thing that decide it. We wanted to generalise this but there
+is a problem in that if the style is the only thing its hard to make pop-up
+menus and other things that are specific to certain feature types unless
+you add a feature type field to the method/style which means that now the
+style is the feature...and in any case the feature just contain exons etc
+so it is the feature as well...it just doesn't really work...
+
+So this is our sytem which is a blend...
+
+
+Feature				drawn shape			Style
+
+
+BASIC		=>		read shape from style		read shape as basic box,
+								splice markers (for genefinder)
+								constant shapes (for alleles)
+
+
+TRANSCRIPT	=>		usual transcript shape		read for colours
+
+
+ALIGNMENT	=>		usual align shape		read for colours
+
+
+This works because there three basic feature types should be enough to allow popup menus etc
+to work well but then we can avoid having endless types fields for alleles etc by having a
+drawing type in the style which will sort all this out.
+
+So in otherwords, the feature type decides what type of main shape the feature will be
+drawn as, but the style allows tailoring of the basic feature types.
+
+
+
+