User Tools

Site Tools


pentominos:artefact

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
pentominos:artefact [2009/02/26 12:55] devapentominos:artefact [2010/03/31 12:24] (current) deva
Line 1: Line 1:
 ======Artefact====== ======Artefact======
 +[[LUA Scripts]]
  
 +====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?"
 +  * If the transaction contains a single data entry, the server should respond with the status of the insertion of that entry. 
 +  * If the transaction contains several data entries, the server should respond with the status of the insertions of these entries. 
 +    * We need a way to map a status message to an entry. 
 +    * We need a status message system that can contain several status messages. 
 +  * If the transaction contains both data entry (or entries) and query (or queries), the server should respond with the status of the insertions as well as the answer to and status of query (queries). 
 +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'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.
  
 ====The data transportation path==== ====The data transportation path====
Line 74: 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 83: 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:client]]+[[pentominos:feed]]
  
  
Line 102: Line 119:
   * {{:check.png}} Replace xerces-c with eXpat.   * {{:check.png}} Replace xerces-c with eXpat.
   * {{:uncheck.png}} Make SQL comm functions for the LUA programs return all results and not just the first one.   * {{:uncheck.png}} Make SQL comm functions for the LUA programs return all results and not just the first one.
 +  * {{:uncheck.png}} Make all use of time (struct time_t and postgresql timestamps) [[http://en.wikipedia.org/wiki/Year_2038_problem|Y2K38]] safe.
  
  
pentominos/artefact.1235649354.txt.gz · Last modified: 2009/02/26 12:55 by deva