separate the grisly internals from the user-facing README

HACKING.md

@@ -0,0 +1,62 @@
+# Development and Design notes
+
+
+## WIP, Puzzles and TODO
+
+* rename Track to Gpx, it deals only with parsing.
+* can we lose this "if isJust lat && isJust lon && isJust ts" wart?
+* probably we should store points in a more efficient form than
+ a singly-linked list
+
+* boring stuff like auth[zn]
+* need a web server in haskell that
+    * [done] accepts file upload and parses the gpx file
+    * [done] serves the data points in some format elm can digest easily
+* [done] need a database of some kind so the data can be saved
+* [done] frontend can get data from backend
+* [done] for DX, backend can serve the js files needed by frontend
+* [ad hoc] we only have yesod-core, may need other parts as well
+* [done] detect and refuse uploads which overlap an existing time frame (http 409) so that we can script upload-all-the-tracks.
+* could we converge the Point and Trkpt to make sql better?
+* [done] move Store into Point
+
+* on timeline, show power, cadence, speed, height, ascent (checkboxes)
+    * done some
+    * need speed and ascent
+    * need checkboxes
+* zoom gesture on graphs causes map to adjust
+* zooming map causes graphs to adjust
+* threshold display: adjust vertical slider to show time spent at
+  or above a particular intensity. Indicate somehow the length of
+  each continuous stretch at that intensity
+
+## Sessions
+
+
+The calendar (TBD) displays sessions. a session is a sequence of
+measurements describing a ride or a race or a trip. we can extract
+potential sessions from the data by looking for series of points not
+more than x (10?)  minutes apart, but the rider may override
+that. Consider: I ride solo to the start point of a group ride, join a
+tandem partner to do the group ride, then ride solo home. There is not
+necessarily ten minutes between them.
+
+After a new track is uploaded, we look at all the points covered by
+draft sessions, and rearrange them to cover the new points.  Draft
+sessions are then presented to the rider who may approve them as-is -
+perhaps involving other data collection as well ("perceived effort" or
+"which bike setup was this" or ...) - or chop them up using
+information they have but that the computer doesn't
+
+Aside: in theory we don't even need draft sessions and we could have
+the rider create sessions from the calendar page. However, that's a
+GET and might be slow if it has to figure out what all the sessions
+would be every time someone looks at it. So the draft session is just
+to precompute that and make the view easier
+
+The summary of a session is for display on the calendar and might
+change depending on the nature of the training effort. e.g.  for a
+long slow ride we show total distance, for interval training we show
+time spent in HR zones ...
+
+-

README.md

@@ -71,65 +71,3 @@ that you can chuck a bunch of GPX files at it using curl
 This should be safe to do repeatedly because it will refuse upload of
 tracks where the database already contains any points in the time
 range of the uploaded track
-
-----
-
-_Do not look below this line_
-
-## WIP, Puzzles and TODO
-
-* rename Track to Gpx, it deals only with parsing.
-* can we lose this "if isJust lat && isJust lon && isJust ts" wart?
-* probably we should store points in a more efficient form than
- a singly-linked list
-
-* boring stuff like auth[zn]
-* need a web server in haskell that
-    * [done] accepts file upload and parses the gpx file
-    * [done] serves the data points in some format elm can digest easily
-* [done] need a database of some kind so the data can be saved
-* [done] frontend can get data from backend
-* [done] for DX, backend can serve the js files needed by frontend
-* [ad hoc] we only have yesod-core, may need other parts as well
-* [done] detect and refuse uploads which overlap an existing time frame (http 409) so that we can script upload-all-the-tracks.
-* could we converge the Point and Trkpt to make sql better?
-* [done] move Store into Point
-
-* on timeline, show power, cadence, speed, height, ascent (checkboxes)
-    * done some
-    * need speed and ascent
-    * need checkboxes
-* zoom gesture on graphs causes map to adjust
-* zooming map causes graphs to adjust
-* threshold display: adjust vertical slider to show time spent at
-  or above a particular intensity. Indicate somehow the length of
-  each continuous stretch at that intensity
-
-
-* calendar displays sessions. a session is a sequence of measurements
-  describing a ride or a race or a trip. we can extract potential
-  sessions from the data by looking for series of points not more than
-  x (10?)  minutes apart, but the rider may override that. Consider: I
-  ride solo to the start point of a group ride, join a tandem partner
-  to do the group ride, then ride solo home. There is not necessarily
-  ten minutes between them.
-
-  after a new track is uploaded, we look at all the points covered by
-  draft sessions, and rearrange them to cover the new points.  Draft
-  sessions are then presented to the rider who may approve them
-  as-is - perhaps involving other data collection as well ("perceived
-  effort" or "which bike setup was this" or ...) - or chop them up
-  using information they have but that the computer doesn't
-
-in theory we don't even need draft sessions and we could have the
-rider create sessions from the calendar page. However, that's a GET
-and might be slow if it has to figure out what all the sessions would
-be every time someone looks at it. So the draft session is just to
-precompute that and make the view easier
-
-the summary of a session is for display on the calendar and might
-change depending on the nature of the training effort. e.g.
-for a long slow ride we show total distance, for interval training
-we show time spent in HR zones ...
-
-----