[sugar] Journal integration design for Measure Activity

[Eben Eliason]

> > 1) Since many logs are going to be associated with one logging
> > session, what is the best way to pack these log files and
> > associate with the journal? Should one make a .zip file of
> > all the log files ?
>
> That's OK, but don't waste effort on compression.
> Standards say you use the pax format, or at least
> something like tar or cpio.

Interesting point.  Perhaps, with our filesystem, we should always
prefer something other than zip for bundles?  Tar would be a good
pick.

> > 2) There are other details associated with each logging session -
> > like what is the time interval of logging selected while the log
> > was made etc. which I have been writing down within each log file
> > itself in the first few lines, should I follow the same practice ?
>
> You can put sample rate info in the header of a *.wav file.
> This is really the perfect format for your data.

I'm not sure I necessarily agree with that.  As a text file, it would
be possible to crack open logs with a text editor, or in the future, a
spreadsheet activity of some kind.  I'd much prefer to keep the data
in simpler formats, when there aren't negative consequences to doing
so.

> Use FLAC if you want to get fancy.
>
> > 3) It may also be possible that within a session of Measure,
> > no logs be made. However the user have selected some settings
> > with which he/she was making some measurements. For example
> > DC/AC mode, gain setting and a time base setting etc. The user
> > may want to resume such a session from the journal. How should
> > such details be handled ? Do I need to write them down into a
> > text file ? The settings comprise of states of 3 toggle buttons
> > and 2 sliders.
>
> Whatever you do, don't spam the journal.

This is strictly metadata about a particular entry that will exist
anyway.  I don't see any spam problems here.

> I just finished deleting a huge pile of spam from my journal.
> Well, not counting the two things that refused to be deleted.
> This was not an enjoyable task. As with an email inbox, I run
> a risk of deleting something I want to keep as I wipe things
> out. This stupid busy-work chore should never be needed.

Agreed.  There are a few things that can and should be done up front,
but in the long term the Journal is going to perform intelligent
collapsing of versions and also provide automated "garbage removal"
(or at least, garbage flagging) so that this process isn't a burden on
the owner, but a natural extension of the core ideas of the Journal as
a filesystem.

> A few buttons is nothing. If it gets to be dozens of buttons
> or more, then you might add a "save settings" button. Hopefully
> you can save this with the activity itself, rather than putting
> more junk onto the desktop^H^H^H^H^H^H^Hjournal.

The whole point of the system is to prevent the need for manual
saving, and to emphasize the idea of sessions, which means that
session state is really important.  In any case, this is still
independent of the spamming problem, which arises from "empty" entries
(which should indeed be avoided) and from frequent use of an activity.
 Still, if the emphasis on sessions takes hold, one should more often
than not be resuming an old entry, rather than making a new one all
the time.

- Eben