note some plans for the Session

README.md

@@ -73,10 +73,35 @@ _Do not look below this line_
 * 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
-* detect and refuse uploads which overlap an existing time frame
+* [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?
 
+* 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 thy have but 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 or the timeline
+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 ...
 
 
 ## Postgres