pentominos:artefact
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
pentominos:artefact [2009/02/26 09:47] – created deva | pentominos:artefact [2010/03/31 12:24] (current) – deva | ||
---|---|---|---|
Line 1: | Line 1: | ||
======Artefact====== | ======Artefact====== | ||
+ | [[LUA Scripts]] | ||
- | ====LUA elements==== | + | ====Reply problems==== |
- | | + | The outline of the problem is, "when is it possible to return status information to the client, and when is it actually needed?" |
- | | + | |
- | | + | |
+ | * We need a way to map a status message to an entry. | ||
+ | * We need a status message system that can contain several status messages. | ||
+ | | ||
+ | Should (can) the status message be treated as just another query?\\ | ||
+ | \\ | ||
+ | ===Proposition=== | ||
+ | Data and Query cannot be located in the same transaction. | ||
+ | Query works as it does now (it reply' | ||
+ | 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. | ||
- | ====Snaask==== | + | ====The data transportation path==== |
When an apparatus is connected the following must be crafted: | When an apparatus is connected the following must be crafted: | ||
* Feed parser so file and conf. | * Feed parser so file and conf. | ||
- | * Artefact | + | * Artefact |
* Makes superficial parsing of the data to identify whether the data is valid. | * Makes superficial parsing of the data to identify whether the data is valid. | ||
* Figure out what classes are contained in the data, and report this. | * Figure out what classes are contained in the data, and report this. | ||
- | * Artefact interpretation | ||
- | * Parses and interprets the data, translating it into some output language (eg. xml) | ||
- | (data, class) => [lua] Parser | + | |
+ | * Artefact interpreter. | ||
+ | * Parses and interprets the data, translating it into an internal tree structure. | ||
+ | |||
+ | (data, class) => [lua] Parser -> [lua] Interpretation -> [lua/c] Tree structure -> [c] Pretty printer -> network | ||
+ | |||
+ | ===Template code=== | ||
+ | <code lua> | ||
+ | -- | ||
+ | -- Read the data from < | ||
+ | -- | ||
+ | -- 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 < | ||
+ | -- contains values determed by the interpreter. | ||
+ | -- | ||
+ | -- The following functions are available in the interpret function: | ||
+ | -- - addGroup(parent, | ||
+ | -- 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, | ||
+ | -- 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: | ||
+ | f.close() | ||
+ | |||
+ | return data; | ||
+ | end | ||
+ | </ | ||
====Patient registration==== | ====Patient registration==== | ||
Line 33: | Line 90: | ||
A server listen will run in a read loop until the client terminates the connection.\\ | 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 server must reply to all request with an answer, no matter if the preceding processing went well or not. | ||
+ | |||
====The client==== | ====The client==== | ||
Line 42: | Line 100: | ||
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. | 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: | + | [[pentominos: |
Line 61: | Line 119: | ||
* {{: | * {{: | ||
* {{: | * {{: | ||
+ | * {{: | ||
pentominos/artefact.1235638031.txt.gz · Last modified: 2009/02/26 09:47 by deva