The zmapServer module exist to provide concurrent thread base interfaces to external databases. It uses the zmapThread module.
zmapView contains some notes about requesting data from pipeServer modules and other issues.
pipeServer details usage of that module.
Threads some notes about thread startup and shutdown.
Server layering
Traditionally with a single ACEDB server this will have been kept active with ZMap and ZMap would not run without it. With the advent of pipeServers being used to request data on demand it becomes necessary to have threads startup, run and then be cleared up, a function that has been planned but not implemented. There is code to kill off threads on shutdown, but the threads code does not include a clean exit!
Tasks that need doing include:
The server protocol as implemented and used with ACEDB specifies coordinates base from 1 for the region of chromosome stored in an ACEDB and there is currently no way to specify chromosome coordinates (or chromosome, or species) in ZMap. This leaves some implementation difficulties for pipes in that each pipe is specifies as a URL with GET parameters giving this information (ie defined statically and externally). To requests a subset of the the whole alignment it is necessary to request this in ZMap coordinates ie based from 1 and covering the implies sequence range.
Data is normally requested using coordinates 1,0 and this specifies 'the whole sequence'. Subsets of the whole sequence may be requested by coordinats relaitve to the local sequence based from 1.
There are some legacy issues with this in that sequence coordinates are specified by some feature context data supplied to the server at some point in the request process after the server has bee created and opened. As a pipe server is regared as a script that simply provides a GFF stream there is no interaction with the server protocol as defined for ACEDB after starting the script (and this is not desired as it would introduce needless complexity). As a temporary implemntation ZMap base coordinates are appeneded to the pipe server arguments, and the coordinates are also stored in the features contect block as supplied to the thread.
Both ACEDB and pipe servers process GFF data and create populated featureset data structures held in a GFF parser data structure while reading the data stream. Subsequently in another server protocol function these featuresets are added to a feature context block supplied by the ZMap application.
This is problematical as:
There is a need to display chromosome coordinates (to allow users to communicate with others) and currently these are extracted from the sequence name.
It should be possible to specify species chromososme and seqeuence coordinates to pipe server scripts and still present ZMap style (based from 1) coordinates to the user (which is useful as chromsome coordinates are too big and Zmap coordinates give some sense of scale. This would imply specifying pipe server script arguments for this data, and thse can quite easily be designed by referring to the exosting pipe server script URL currently in use, and this is a necessary step to provide true standalone operation for ZMap. For a given session these could be specified in a stanza in the Zmap configuration, or given in the main window.