[sugar] DS possibilities

[Benjamin M. Schwartz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Based on these options, I personally recommend that the priorities be:

1. Write a new datastore implementation to the same API.
1. Set up a datastore test system.
2. Improve logging.
- --- Future ---
3. Write a new datastore implementation with a new API.
3. Notify the user when things go wrong.

My recommendation is not very strong.  I can see many other reasonable
arguments.  However, I prefer this one:

After glancing at Michael's Simple Data Store code, I am convinced that it
would be easy to turn it into a complete implementation of the current
datastore API, with a backend that is simply individual files in the
filesystem.  Search could be implemented by grep -R, or something of
similar complexity.  I would be perfectly happy to replace the current
datastore layer with this one (though the upgrade mechanism will take some
careful thought).  If some code from the existing implementation is still
applicable, then it may of course be reused.  Indeed, the rewrite vs. fix
distinction is something of a false dichotomy; the major issue is whether
or not to use Xapian and other advanced algorithmic designs.

The principle objection to this path, it seems to me, is the possibility
of introducing new (worse) bugs.  A datastore test system would greatly
increase confidence in any new implementation.  If the test system can
also reproduce crashes in the current implementation, then we may
determine with some confidence whether the new implementation is more
reliable (under those circumstances).  Logging goes hand-in-hand with
testing; it is needed in order to determine the results.  Having better
logging in production laptops will be a positive side benefit.

I recognize the importance of providing version control functionality
within the datastore, but the deadline for this work appears to be July,
pending an August release.  It seems unlikely to me that any
future-proofed version control system could be completed, and integrated
with the rest of the system, in two months.  If anyone wishes to argue the
opposite point, I will be happy to listen, since I desire this feature
greatly.  If the version control project is sufficiently important, it may
be acceptable to place an expert (presumably Scott) on this full-time
targeting a December release.

Notifying the user when critical system components stop working is a good
goal as long as it doesn't distract from the more important work of making
the critical system components work reliably.  It seems to me that the UI
team's work on the wide variety of frequent, user-interaction
notifications is far more important, and also sets the stage for this work
later.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFID5npUJT6e6HFtqQRAnV7AJwKP/QR+QMOBxLraC86Di3OuHTsKgCffm2S
lgtGafE1/xSGITLXWDyFZhE=
=hfOU
-----END PGP SIGNATURE-----