This document is intended to summarise the various issues which the prototype handler is intended to resolve:
| Name | Description | Resolution plan |
|---|---|---|
| CCP4i backend | The CCP4i flat-file database backend is fundamentally different from the mySQL implementation, and so the implementation needs to be documented. The flat-file backend will most likely need to be reimplemented (and possibly not in Tcl). | |
| Client attributes | What attributes do client applications have? For example, do clients operate on behalf of users? Do clients connect synchronously or asychronously to the handler? Do clients need to "watch" the database? Are there different types of client? | Identify different types of client and client attributes via "use cases" or similiar |
| Communication protocols | How are requests and responses passed between the application and the handler? This includes dealing with the names of the requests that are passed between the handler and the clients. | |
| Connection persistence | How persistent does the connection between the client and the handler need to be? | |
| Database backending | Does the handler application need to deal with arbitrary abstract database backends, for example ISpyB? That is, does the handler need to be able to retrieve data from an arbitrary database with a different database structure, items etc than that implemented by this project? | |
| Data persistence | How persistent is the data stored in the database? Some data may only be stored for the lifetime of a job, other data may be required afterwards. | Identify how data will be used via "use cases" or similar |
| Data transfer | How is information transfered between different databases (e.g. facility databases, LIMS for wet labs, the tracking database). How do these overlap or complement each other in terms of scope etc? | Begin dialogue with other interested parties about their requirements |
| Data types | What kind of data are we storing (e.g. items of text? compound data items such as cell parameters? more sophisticated objects such as python pickles?) | |
| Error Checking | Whar error checking needs to be performed? (e.g. checking that project names are unique) Where is this checking performed? (e.g. in the clientside API, in the handler) | |
| Installation | How difficult is it for non-expert user to install and use the system? | |
| Languages | What languages do we need to provide APIs for? (Python, Tcl, C? Java?). Are there any language-dependent features in our implementation? | |
| Performance | What volume of data can the system handle (store, transfer)? Are there issues with speed of access, response times etc? | |
| Portability and dependencies | What platforms can the handler and database run on? What packages does the system depend on to run? (e.g. python and mySQL) What are the minimum versions required from each dependency? | |
| Security | Security issues include: permissions on data for individual users and/or client applications; protecting against malicious attacks; authentication (checking that the requests it receives are from a trusted source) | |
| Testing | How do we test the handler? What are we trying to test? | Identify areas to test by considering the requirements for the handler and the database? |
| Tracking | How do we incorporate the concept of subjobs? i.e. a job which is the child of a previous job? |