Future FormatConverter design

We're assuming that what the user ideally wants from an interface is the following:

• • Format-specific import and export, where the interface reflects the peculiarities of that format.

  • Intelligent interpretation of the input files so that the user only has to answer relevant questions.

  • Intelligent interpretation of the information in the data model for export to files.

  • Interact with the user in the terms they understand and use daily, basically hiding the data model complexity and terminology as much as possible.

  • Clear error reporting, with the possibility to automatically mail the error to developers for a bug fix.

What this will require is:

• • Surveys and continuous interaction with the community in order to:

    • ensure that the assumptions above hold true

    • identify the terms users use daily

    • identify the import/export processes the users need most

    • ensure that what is being developed makes sense to the community

    • the above have to be an important part of the development process

  • A complete rewrite of the GUI interface with:

    • custom-written popups per format (currently these are all dictionary based and automatically generated)

    • custom-written 'intelligent' logic per format which tries to guess what users want

    • the above should result in a minimal number of questions presented to the user. These questions should be gathered in the trial run described below, and should appear all at once so that the conversion process itself will run through to completion without any additional input from the user

    • possibly switch to another framework (not Tcl/Tk) for easier development

  • A setup where the import/export process can be 'trialled' before it is executed, so that possible questions and errors can be identified using the validation built into the CCPN framework.

    • this will probably need a roll-back mechanism or a complete in-memory copy of the CCPN project

    • the core FormatConverter code can then be adapted so that possible errors and all questions are 'collected' during a trial run and fed back to the interface

    • alternatively the whole core layer can be rewritten, but this would greatly increase the need for testing and development

In any case, this would be a major effort which needs a dedicated developer (and funding) for at least a year, probably more.

Additional notes:

• • A start was made with more 'intelligent' handling of the input in the FormatConversion wrapper (which underlies the web interface), but this is still handling most formats generically with little custom code.

  • There are two components to the FormatConverter: the import/export code (DataFormat and related) and linkResonances (for linking newly created resonances to atoms). In order to 'collect' errors and interaction information, the overall structure of these should not have to change - however the functions (or code) would have to be wrapped to trap errors, and all current interaction would have to be modified so that it can be collected (in a dictionary, or whatever).

  • A complete rewrite of the import/export code will probably make the development of the interface part somewhat easier, but since the core FormatConverter code works well (despite not being as transparent as it should be) it is unlikely to be really necessary.

  • Maintenance after development is essential for this to keep on working, especially with format-specific custom-written interfaces: formats change, new ones appear, errors creep up, and things might change on the CCPN side...

Specific issues to address:

• • Handling Pdb and pseudoPdb as a single option with automatic choice between the formats