[rucksack-devel] Rucksack philosophy

[Arthur Lemmens]

Nikodemus wrote:

> * A persistent object always belongs to exactly one rucksack,
>   which must be open for the instance to be valid.

Yes, I agree.

> * The rucksack the object belongs to is the sole arbitrer of
>   its identity: EQ is meaningless when talking about persistent
>   objects.

Yes, I agree.

> * References to non-root persistent objects outside transactions are
>   forbidden. Root-objects are (1) objects in RUCKSACK-ROOTS, (2)
>   indexed objects [maybe (3) lexical roots declared with WITH-ROOTS].

Like you wrote in another mail today, I think it's better not to have
any references to persistent objects outside transactions at all.

> * Reading and writing a persistent slot outside a transaction is
>   forbidden.

Yes.

> * Transaction provide basic ACID properties, though the level of
>   isolation may be in variance with the usual definition.

Yes.

> * Enforcement of semantic constraints is preferable when possible
>   without extreme costs.

Yes.

> * Correctness is paramount.

Yes.

> * Flexibility is more important then extreme speed.

Yes.

> * Portable Common Lisp. (Accepted extras limited to threading & MOP.)

Yes.

> Am I on the right page?

Yes.

> * Nested transactions: do we want them? (My gut feeling would be
>   to prohibit them initially: they can always be added later.)

I agree.

> * Is the serialization API part of Rucksacks public interface?

Hmm... My idea was that you'd have different levels of 'public interface'.
The highest level is for programmers who just want to use the damn thing
and don't want to be bothered with details about indexes, garbage
collectors, caches or whatever.

At a lower level you'd have protocols for extending Rucksack.  Defining
a new kind of index, for example.  Or maybe creating a persistent sparse
matrix as a subclass of persistent-data.  Or whatever.  At this level,
I suppose you may want to use some of the serialization functions.  So
yes, I think that may be useful.

Arthur