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: by deva
