1 sep 2010 nots

The database structure right now uses text files, and xml files. 

Some of the basic data stored as XML files should be kept in that format

since it is meant to be transfered to the clients (who will then read the
xml file and extract relevant information).

Other data is stored as text files. 

The questions is: should the current data storage structure be replicated.
Or should a new structure, that uses mysql databases, be implemented.

Probably the latter is more efficient in the long run. But it does require
more thought.

But before we get to that problem, we must first implement the basic tasks
I outlined earlier. The ones having to do with saving and retrieving files
and "variables"?

But just for fun, attached are a couple of files from the sample session
you guys were part of.


joinlist.txt : when a client joins a session, the server adds a new line
            to this text file  Clearly, this could easily be implemented as an mysql
            database (so the  server when add a new line to a session specific
          "clientList" database).
             Note that the "refid" variable can be assigned later (after a
             client joins a session).

params.xml :  the "session specific" general parameters file (variable
               whose values are the same for all clients).
              It is created when a session is created. 
              It can be modified by the session administrator BEFORE clients join.
              When a client joins, he downloads this file.

reference.xml  : the "session specific" client-specific information file.
              It is created when a session is created. 
              It can be modified by the session administrator BEFORE clients join.
             When a client joins, he downloads this file.
             The client only uses the record whose id matches his reference id

submitData.txt : File containing information submitted by the client. 
                The client will structure a text message that is then appended to this file.
                Note that this text message has an "xml" like structure, beginning with:
                 <data id=".....>
                    and ending with a
                </data>
          This is done so as to make it easy for the server to send this information as an
         XML file to the  administrator. The administrator can then parse this xml file.

          It shouldn't be that difficult to save these strings to a session specific "submitData"
         mysql file.  That is, the strings would be saved as is, with no attempt to read the
         variables they define.

         Now, if might be cool and groovy to break this down, and have the variables
         (specified in this text string) saved seperately in a mysql database. But it isn't worth
         the trouble.

submitMessages.txt : File containing data on submission status
       A line is added to this file by the server whenever a client submits information.
       Note that this complements the data saved in submitData.txt.
       In particular, when a client submits information it includes the string saved in 
       submitData (the data of interest), and also some status information.
       The server saves the data (as noted above) to submitData.txt.
       And, the server takes the status information and saves it to submitMessages.txt.
      The server also saves other information (such as time of submission).

       This also could easily be saved in a session specific mySql database.

  Note: the various session-specifc "mySql databases" I mentioned above could be
  seperate table in a single mySql database file. I don't know mysql well enough to
  know what would be easies (a single file with several tables, or a seperate table per file).
  I would lean toward the latter.

saveGeneral.txt:  File containing round specific information.
   This is created by the administrator.  It contains a round-by-round history of what
   "general" parmeters were used (in the round). 
    As with submitData.txt, each line is an xml-like record. Each line is created by
   the administrator, and the server simply appends the line to this file.

saveHistory.txt : File containing client-round specific information.
    Each line is created by a client. Thus, this file mixes information that is submitted by
    one or more clients.  It is used to display a history of actions, for each client.
   As with submitData.txt, each line is an xml-like record. Each line is created by
   a client, and the server simply appends the line to this file.


-----
Simple tasks (1 august 2010)


  Basically, a set of "requests" to the server need to be
  constructed. These requests will ask for information stored on the server, or transmit
  information to theserver that may be requested at a later date.
 
  These requests should be structured as simple URLs. That  means they should have
  a fairly easy to understand structure.  Earlier I sent you  a set of "header" javascript
  files that contain examples (I will include other   examples).
 
  The point: in my javascript programs I will replicate these  kinds of urls.
  Any given url will contain custom fields, that specify  exactly what information
  is desired (or contained).
  Note that there may be several variants of these URLS, with  each variant requesting
  (or transmitting) a different type of information.
 
  So below is a beginning set. I will specify a complete set in a week or two.
 
  Note: How will you do this? I presume you will create   requests to PHP scripts (that
  will reside on the server). These scripts may access mySql   databases, or may
  access files.  I have used files for data storage, but if  you can show that
  php communicates VERY quickly with mySql databases, you can
  use mySql databases.
 
  1) Ask for string variable that is "session" specific.
    The server should maintain string variables that are   "session" spedcific. Note that
   there may be one, several, or many "sessions" active at  any given moment. And each
   of these sessions may support a varible with the same   name.
   For example, each session may have a NCLIENTS variable --  that records how many
   people are participating in the session.
 
   Possible structure of the URL
         /xxx?session=sessname&var=varname
   where
        xxx :  refers to whatever script will handle the request.
               For example,  /dsurvey/scripts/getVar.php
   sessname : a one word session name. For example: SJULY22
   varname  : a one word variable. For example: NCLIENTS
 
   (note: this should all be case insensitive)
 
   The response should be a short string (containing the  value of the variable)
 
  2) Ask the server for several session specific string  variables.
     Simlar to above, but several variables are asked for.
 
   Possible structure of the URL
         /xxx2?session=sessname&var=varname&var=varname2
 
   where:
    xxx2 : could be the same as xxx above
    sessname : same as above
    var:  similar to above, but now you can have several  instances of var
 
   If this is too tricky, an alternate syntax is:
         /xxx2?session=sessname&vars=varname1,varname2,...,varnameN
 
   vars now contains a list of variables, each seperated by  a comma. You don't have to
   use a ","; a "-" might be better (or a ":"). Depends on  what PHP, etc are most comfortable with
 
  3) Save a session specific variable to the server
      Possible structure of the URL
         /xxx3?session=sessname&var=varname&value=avalue
 
     xxx3:  perhaps /dsurvey/setVar?
     avalue: a "url encoded" string to save. If you don't  know what URL encoding is,
            you need to learn (i,e. " " is transmitted at  "%20")
 
  4) Return a session specific XML file
      Possible structure of the URL
         /xxx4?session=sessname&xmlfile=filename
 
      xxx4: perhaps /dsurvey/getFile?
      xmlfile: name of an xml file (with or without a .XML  extension)
 
    As with the above, this file will be specific to a  "session".
    And, as an XML file, it will have legal xml structure.
 
  5) Return a session specific text file
         /xxx4?session=sessname&file=filename
 
      xxx5: perhaps same as xxx4
      file: name of any file (must include extension)
 
 
  6) Return a list of active sessions
 
         /xxx6?
 
      xxx6: perhaps /dsurvey/activeSessions?
 
     Currently, whenever a session is created a  "sessName.xml" file is created in a
     /dsurvey/sessions directory.  Note that a  /dsurvey/sessions/sessname directory
     is also created.
     So, one could return a list of all the "sessName.xml"  files in the /dsurvey/sessions
     directory.
 
     Or a mySql database could be used to track sessions (as they are created and destroyed)
 
 
 


