pentominos:pentominos
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
pentominos:pentominos [2009/02/24 14:00] – deva | pentominos:pentominos [2010/01/29 08:46] (current) – deva | ||
---|---|---|---|
Line 3: | Line 3: | ||
The Pentominos project consists of several sub-projects, | The Pentominos project consists of several sub-projects, | ||
Here is a list of the current sub-projects: | Here is a list of the current sub-projects: | ||
- | * Artefact - The data storage server. | + | * [[Artefact]] - The data storage server. |
- | * Feed - A thin client data gathering application. | + | * [[Feed]] - A thin client data gathering application. |
- | * Upload Server - Journal writer. | + | * [[Upload Server]] - Journal writer. |
- | * Pidiod - The uid => patient ID mapper. | + | * [[Pidiod]] - The uid => patient ID mapper. |
- | * Pidio - The uid => patient ID mapper client (numpad/ | + | * [[Pidio]] - The uid => patient ID mapper client (numpad/ |
- | + | | |
- | ====Patient registration==== | + | |
- | The system stores data. These data is connected to a patient ID, a timestamp, a location and an apparatus.\\ | + | |
- | Getting the patient ID is a non-trivial task at best.\\ | + | |
- | See the [[pentominos: | + | |
- | + | ||
- | ====RFID tag project==== | + | |
- | [[pentominos: | + | |
- | + | ||
- | ====Network communication (protocol)==== | + | |
- | All network communication are done via XML documents.\\ | + | |
- | < | + | |
- | Sending the zero character to a process will reset it, and thereby cleaning up all mess made by illegal documents.</ | + | |
- | A connection can only be created in client-mode, | + | |
- | A server listen will run in a read loop until the client terminates the connection.\\ | + | |
- | The server must reply to all request with an answer, no matter if the preceding processing went well or not. | + | |
- | + | ||
- | ====The client==== | + | |
- | The client reads its config file, and forks for each config section it encounters.\\ | + | |
- | Every fork handles a single apparatus according to the attached config section.\\ | + | |
- | The main thread runs infinitely and makes sure to terminate all client forks upon termination.\\ | + | |
- | Every client is connected physically to a port on the host computer, and a LUA program runs to determine whether data is ready to be read or not.\\ | + | |
- | The LUA programs hereafter sends this data to the server indirectly through a number of exposed c methods.\\ | + | |
- | Each LUA program must run in an infinite loop, terminating only when the function stop() returns true, and it must not hang waiting on read, but rather have a time-out, and loop again. | + | |
- | + | ||
- | [[pentominos: | + | |
- | + | ||
- | + | ||
- | ====Data types==== | + | |
- | Problem: An apparatus produces more than one type of data, but stores all measured values in the same data block. | + | |
- | How to make a query that will hit this multi-data block?\\ | + | |
- | Solutions: | + | |
- | * Make the validator insert one entry in the db for each data type, referring to the same data block (file). | + | |
- | * The data are only stored once in the file system. | + | |
- | * We don't need to make drastic changes to the server code (or client for that matter). | + | |
- | + | ||
- | ====Links==== | + | |
- | * http:// | + | |
- | + | ||
- | ====TODO==== | + | |
- | * {{: | + | |
- | * {{: | + | |
- | * {{: | + | |
- | * {{: | + | |
- | + |
pentominos/pentominos.1235480435.txt.gz · Last modified: 2009/02/24 14:00 by deva