[sugar] Journal integration design for Measure Activity

[Albert Cahalan]

On 10/22/07, Eben Eliason <eben.eliason at gmail.com> wrote:
> On 10/21/07, Albert Cahalan <acahalan at gmail.com> wrote:

> > 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.
>
> Obviously I know little about the .wav format, so perhaps you are
> right.  My only point is that, as far as I understand it, the logs are
> really just a list of samples (time, value), which are at least a
> second apart.  Is there really a reason to use an audio format for
> what amounts to a simple list of tuples?

I don't see this data as being tuples at all.
It's not even x-y data.

Timing is perfectly regular. Doing an FFT on irregularly
spaced data is awkward, though possible.

Audio file converters already exist. Loading and storing is fast.
The storage is efficient.

Measure should also be able to open audio files
from elsewhere. (and inefficient stuff like CSV too)
Think about looking at sounds from Record or TamTam
in Measure, or playing sounds from Measure elsewhere.

> > 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.
>
> This is an essential path when there is so little storage on these
> machines.

That isn't small unless you waste it. Waste would be
using XML, using CSV, using wordprocessing formats
when you only need plain text, spamming the journal,
and so on.

Don't you remember using computers with far less
than a gigabyte of storage? Not even counting the
stuff prior to the graphical internet and high-resolution
screens, I had at least 3 operating systems installed
in 1.6 gigabytes back around 1996. One of those was
NT, and one of those included multiple copies of the
Linux kernel source. I kept that setup for years.
It worked very well.

> > Second of all, starting an activity fresh is simply much easier
> > than starting it from the journal.
>
> This is most certainly an invalid assumption.  Specifically for
> reasons like the list of stored state above, returning to a known
> state can save time.

Fresh: hit frame button, click on activity

Restart: hit home button, click on journal, spend time hunting
around in the disorganized mess, click to get the activity going,
manually delete the old data and restore default settings