...and also install and test them using CI

archivesink should thread so that it can return quickly from message() and have the thread do the io waiting on couch. couch takes parallel write requests way better anyway, so this is good stuff all around.

perhaps have a pool of threads for couch? or alternatively just spawn a new thread for each message.

• payload_config: for the parser. Sort: [callsign, '{un,}approved', end] approved will sort before unapproved and will be used first.
• flights: for the web ui flight list and dl-fldigi. Sort: ['{un,}approved', 'end'], allowing guis to place dev docs in another tab or exclude in download to save bandwidth.

• removes unapproved docs older than a few months but not if it is the most recent doc for any of the callsigns inside.
• removes unreferenced listener info, listener telemetry, payload telemetry

would work in python3.1 though, instead do this

import logging
class NullHandler(logging.Handler):
def emit(self, record):
pass

then use NullHandler rather than logging.NullHandler

flight doc management, etc

all docs should have timestamp start and ends

• e.g., enter callsign or log in, get list of previously created flight docs
• if logged in, then don't show testing docs created by other users to avoid accidental selection
• perhaps warn if a doc will be shadowed by another, approved, doc (conflict)
• admin interface to approve docs.

unapproved docs are:

• hidden in the web ui (live, archive) by default
• hidden in dl-fldigi by default (have a [X] show dev flights checkbox)
• considered last for parsing, to prevent abuse.

consider e.g. graphite, greplin/scales, statsd, using couch itself, google visualisation stuff, etc

more secure/faster than arbitrary code, but lets views be in python

to test whole-system functionality

especially if integrated with couchdb and the web interface

jsoncpp uses assert dangerously, and will abort if you attempt to access a non-object as if it were an object (i.e., a = [2, 3, 4]; a[“what”] = ) -- this could be bad. Maybe extra error checking is required.

• tidy up the hand-written docs in /docs
• RST and link docs where appropriate
• remove references to config couch docs (that are now in config.yml)

(at least those required for basic behaviour)

File "/home/adam/Projects/habitat_load_test/habitat/habitat/main.py", line 191, in get_options_parse_log_level
parser.error("invalid value for "{0}"".format(levelarg))
NameError: global name 'levelarg' is not defined

• some payloads appear to send 0,0,0 (lat, lon, alt) so the string parses but the point is clearly invalid and messes up the tracker
• some payloads send ,,, so the string does not parse
• curerntly spacenear.us prunes 0,0 points; the habitat web gui demo does this too (hacky addition)

@danielrichman 's suggestion:

• add a fix invalid key; doc[“data”][“fix_invalid”]. Payloads that send a fix valid field can be set from this and the points therefore ignored. Absence of key assumes valid fix.
• perhaps allow payloads to send either empty strings or a special character ‘!’ or something to set the fix_invalid field to false? This is a slight pain to implement.
• add a common post filter that detects if lat == lon == 0.0000 and sets fix_invalid = false, for use on payloads that do not do either of the above
• encourage people to do one of the two first options (or something else, better?)