The outline of the problem is, “when is it possible to return status information to the client, and when is it actually needed?”.
Should (can) the status message be treated as just another query?
Data and Query cannot be located in the same transaction.
Query works as it does now (it reply's with the result of the query in the requested reply-language).
Data returns a (using the same result structure as the queries) series of status messages, each mapping to a Data section by number starting from 0.
Therefore the order in which the Data segments are handled matter!
The reply language of the Data transaction will be the XML language. This might be user defined at some later point. The Queries can be extended to also include a status message list in the reply.
When an apparatus is connected the following must be crafted:
(data) => network -> [lua] Parser -> [lua] Classifier (data, classes) -> [c] Store (db/disk)
(data, class) => [lua] Parser -> [lua] Interpretation -> [lua/c] Tree structure -> [c] Pretty printer -> network
-- -- Read the data from <filename> and determ which classes it contains. -- -- The following functions are available in the classify function: -- - addClass(classname) -- Mark data content as classname. -- - invalidData(errormsg) -- Report that the data is invalid. function classify(filename) -- Load data from file data = loadDataFromFile(filename); -- ID has to equal NIDEK/ end -- -- Interpret data in <filename> creating a tree structure of groups. Each group -- contains values determed by the interpreter. -- -- The following functions are available in the interpret function: -- - addGroup(parent, groupname) // Parent can be 0 if root -- Creates a new group with a groupname refering to a parent group. -- A value of 0 is allowed the group does not have any parents (ie. it is root). -- The function returns a group descriptor refering to the group. -- - addValue(groupdescriptor, valuename, value) -- Adds a value with key valuename to a group refered to by groupdescriptor. -- interpret() must return the root of the created tree structure. function interpret(filename) end function loadDataFromFile(filename) local file = assert(io.open(filename)) local data = f:read("*all") f.close() return data; end
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 registration section for a description of the framework surrounding the registration system.
All network communication are done via XML documents.
Every XML document is terminated by the zero character ('\0' in c/c++)
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, and will exists as long as the client intends it to.
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 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.
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?