The documentation pages are being re-organised and updated.

Some old files are held in ZMap/web and will be moved into ZMap/doc on a gradual basis. The ZMap/Web directory will be maintained during this process as some build scripts depend on it and as the files are in the CVS it provides a backup. Some other files that have been deleted from ZMap/doc have been move to ZMap/doc/old on ~mh17 until they get transferred to the new directory tree.

As files get added or copied or converted they will hopefully get added to this index page, which is intended to be in alpha order. As the number of files increase then we'll add some nice <div>s to put them in pretty columns.

Some things that need investigating and writing up.

• X-Remote appears to talk to zmapControl, zmapView, and zmapWindow, so far. Who is in control?

Things that are slow

• 3-Frame takes a while to paint, likely due to having to do a lot of sums, but hiding it should simply be a matter of hiding the columns, after which a re-painting would also be quick.

• normal thread shutdown needs to be written up and debugged as not previously implemented. View connection data needs to be cleared up.
• pipeServer not to be asked for featuresets or styles to avoid log message
• zmapView.c/processDataRequests() needs to merge the source_2_featureset not just assign it
• delayed server needs to free view_con->context etc etc (memory leak)
• implement X-Remote progress message (source finished has been done, need more detail ie % complete.
• pipe server GFF gives 'cant find style log messages seqRequest() line 1072 (this is a real error in the data)
• sequence server is assumed to be ACEDB or some other server that is not delayed and there can be only one
• Styles have 3 fields that appear to be misplaced as they refer to column data: loaded, deferred, and cur_bump_mode. Most importantly deferred styles need to be looked at esp as commented around zmapViewRemoteReceive.c #1242
• Scope and memory allocation issues with DNA sequence data
• zMapFeatureString2QuarkList() could be moved to zmapConfig and renamed: see zMapConfigIniGetColumns

Here's a list of suspicious bits of code encountered while looking for something else

• In zmpWindowCanvasItem.c zMapWindowCanvasItemGetBounds() looks like a cut & paste of zMapWindowCanvasItemGetFeature() directly above it including the explanatory comment. It's not called from anywhere.