						-*- indented-text -*-

	wx200d infinite TODO list, in no particular order

	If you have suggestions not listed here, or want to help,
	please let me know!  --Tim Witham <twitham@pcocd2.intel.com>


WANNA WRITE A CLIENT?
=====================

Just #include "wx200.h" and link with client.o, buffer.o, parse.o,
unit.o, and format.o as needed.  For an example client, see wx200.c.


PORTING TO OTHER PLATFORMS
==========================

I only use Linux, so I won't be doing any porting.  But if you do and
you don't break anything, then I'd be willing to include your port.

Porting to any other unix should be trivial.  Probably almost no
changes required especially if you use gcc.  You may need to add GNU
getopt.

Porting clients to other OS's is probably also trivial if your OS can
do TCP/IP socket connections in C.  Porting the server to such a
non-unix OS would probably require significant changes to or rewrites
of serial.c and wx200d.c.  I believe most unix-isms are in just these
two files.  The rest of the files should be fairly portable.


CLIENT/SERVER PROTOCOL:
=======================

Establish a (stateless?) command protocol on the client/server
connections; some may require forking a parallel handler for the
connection so as to not interfere with the primary task of gathering
and logging the data.  Example ideas:

	HELP	list these commands that are available

	READ	current default; continuously read data in real-time

	DATE YYYYMMDD	get avg/low/hi info for given date

	NOW	return current data from memory and close

	LIST	return a list of data files available
		(for clients that want to plot historical data)

	GET	send a (compressed?) data file to client

	INFO	give info about the weather station (location, etc.)

	VER	return wx200d program version

	QUIT	close the connection


CLIENTS for WX200D:
===================

* wx200 refreshing could be improved by using ncurses.  This could
  enable interactive unit changing by keystroke commands.

* A wx200 modification could serve as a telnet gateway.  That is, it
  would just listen for connections and return a wx200 screen.

* xwx200 X window client to look just like a real WX200 in a window!
  I've already scanned in some images of the device and plan to write
  this.  On the screen it will be a copy of what is shown on the real
  hardware display.  The buttons will be made functional, so that
  mouse clicks could cycle through the data on the software display,
  independent of the hardware display.  Menus could provide access to
  further capabilities (plot things, replay old data, etc.)

* more "practical" X client that displays more information at a time,
  similar to the software that came with the unit, or to Mike's wx.

* JAVA clients to put WX200 data on the web?  Naaaa.

* On the internet, some client program somewhere could monitor many
  wx200d's at once, providing an overview of weather from many
  stations.  Alternatively, a local client daemon could "report in" to
  the weather center.  For now I'm linking to known stations from the
  wx200d homepage.


WX200D TODO:
============

* file locking on the serial device to prevent conflicting access

* complain if WX200 clock is off by some amount

* there could be an option to record the computer's time and ignore
  the WX200's time since it may be less correct.  Of course memories
  will always use WX200's clock.

* if not using the above option, then use WX200's time to trigger new
  files instead of the computer's clock.

  + this was not done originally to prevent many bogus files getting
    created if you're setting the clock and cycling through a bunch of
    dates.  The downside is you get some of yesterday's data at the
    beginning of the file or some of tomorrow's data at the end due to
    the difference in the clocks.

* tab.c could ignore "insignificant" wind direction changes (+/- 5
  degrees?) to make the log files smaller.  Hmmm, just use unit_dir
  from unit.c to "group" the wind dirs.  Maybe 32 wind direction
  buckets (+/- 5.625 degrees) would work well for real-time.  wxsum is
  currently using 16 buckets (+/- 11.25 degrees).

* does tab.c even need to keep wind chill?  It could be derived.  I
  guess it's nice to keep all actual WX200 variables.

* new "virtual" groups could be sent to clients but not logged:

  + group D: station information like location, latitude, longitude,
    sunrise/set, moonrise/set, comments.  This would be read from a
    wx200d configuration file.

  + group E: todays/this weeks/this months high/low.  Would we also
    want to know when these things happened and keep yesterday, last
    week and last month as well?  We also want rainfall so far today,
    this week, etc.

  + v0.7: lo/hi is no longer needed now that .day and .mon summary
    files exist.  Instead of keeping everything in memory, the server
    could now read requested statistics from the summary files.  Still
    need a way to get rain totals though.


MISC:
=====

* routines to allow clients to plot data

  + GNU's libplot may work but I haven't looked at it yet


Tim's notes for future reference:
=================================
screens shown by mode scan (see user manual page 58 and byte CF.24):

s=0/0/0
s=1/0/0
s=1/1/0
s=1/1/1
s=1/1/2
s=1/1/3
s=2/0/0
s=2/1/0
s=2/1/1
s=2/1/2
s=2/1/3
s=3/0/0
s=3/1/0
s=3/1/1
s=3/1/2
s=3/1/3
s=4/0/0
s=4/0/2
s=5/0/0
s=5/0/0
s=5/1/0
s=6/0/0
s=6/1/0
s=7/0/0
s=7/1/0
s=7/1/1

How to organize the virtual memories?

in hi/lo + out hi/lo * day * week * mon = 12 entries = 72 bytes

daily in hi/lo + out hi/lo humid, temp, dew = 12 entries = 72 bytes

wind gust(6), dir(2) = 8 bytes * 3 = 24 bytes

chill low = 6 bytes * 3 = 18 bytes

rain = 18 bytes

1f: daily highs	44 bytes includes wind hi
2f: daily lows	42 bytes includes chill lo
3f: weekly highs
4f: weekly lows
5f: monthly highs
6f: monthly lows
7f: rain	12 bytes is tot + day + week + mon + timestamp

0f: humid highs	36 bytes	humid in
1f: humid lows			humid out
2f: temp highs			temp in
3f: temp lows			temp out
4f: dew highs			dew in
5f: dew lows			dew out
6f: wind	24 bytes
7f: chill, rain	18 + 12 = 30 bytes

The one on the right above would be best fit.

Rain is current total, day, week, month; timestamp is time of last rain.
To get day, week, month subtract from reference total at beginning of period.
This will break if hardware total is reset.

v0.7: the original thinking above was that the server would keep track
of and send daily weekly monthly lows and highs and timestamps of when
they happened.  Then it would send all this to clients in unused
groups 1f - 7f.  Now, I think this is not practical.  Since .day and
.mon files now exist, I think the server should instead only send this
stuff when queried.  The summary files keep stats down to the day (for
months) or hour (for days).  The server could read a summary file and
populate the binary structures including "close" timestamps and return
that day or month avg/lo/hi image instead of current conditions.
