[sugar] Journal integration design for Measure Activity

[Albert Cahalan]

> > 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.

It's also because general-purpose compression algorithms
do almost nothing with audio data. Ideally the jffs2 compression
would also be avoided.

> > 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.

The simplest format for audio data is an audio file.
Basic *.wav data is really simple. It's a 44-byte header
followed by the raw data.

There are numerous tools that handle *.wav files,
including for data analysis.

There was some plan for an "export as" functionality;
support for other formats could be done that way.

> > > 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.

The entry should not exist. It is spam.

Besides annoying the user, it consumes resources.
The flash will wear out. Power is required to write.
Picture the tired little kid cranking.

> > 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.

Ah. Anybody here who has never lost an email because
it was automatically deleted by a spam filter, or because
they were too careless while trying to delete the flood?

This is not a good path to go down for regular storage.

> > 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.

I don't think this works.

First of all, you're saving at random points. You're not also
saving the undo history. (which would be bad for both privacy
and storage reasons) Without positive action by the user to
indicate that the current version of the user's data is desirable,
there is a chance that desirable state will be replaced by
undesirable state.

Second of all, starting an activity fresh is simply much easier
than starting it from the journal.

Third of all, freshness is good. Experimentation is discouraged
if it leaves a trail of junk. Nobody likes cleaning up old messes.

Even with just the intended stuff, the journal is kind of
unmanagable and confusing. Adding spam into the mix
does not help one bit.