[rucksack-devel] Re: Rucksack, ECLM

[Arthur Lemmens]

Nikodemus wrote:

>> (defgeneric rucksack-import-object (rucksack persistent-object &key deep-copy))
>
> Sounds like a good plan. I assume this would be accompanied by a provided
> function IMPORT-OBJECT-COPYING-SLOTS, but users would need to explicitly
> defer to that? (Like with MAKE-LOAD-FORM.)

Yes, I suppose so.  But I'm not going to think very hard about that until
I've got the basics working.

>  Rucksacks A and B open.
>  Persistent Class FOO is defined.
>  Instances of FOO are stored in Rucksack A.
>  Other instances of FOO are stored in Rucksack B.
>  Rucksack A closes.
>  FOO is redefined, schema in B updates.
>  Rucksack B closes.
>  Lisp exists.
>
>  New lisp sesssion.
>
>  Rucksack A is opened and instances of FOO are fetched.
>  Rucksack B is opened and instances of FOO are fetched.

I *knew* you'd come up with something like that when I wrote my reply ;-)
OK, let's see...

I think the basic guideline should be that rucksacks never need to know
about each other.  And another assumption is that the most recent class
definition comes from your program source, not from a rucksack.  The
schemas in a rucksack are just a way to make sure that Rucksack can adapt
old instances to the current class definition in your program.

So when a rucksack is opened and fetches an instance of FOO for the first
time, Rucksack should probably do the same thing as when a class is
redefined: compare the current class definition with the most recent
schema, and create a new schema if there's a difference between the two.
The new schema will be added to the current rucksack; other rucksacks
are irrelevant at this point.

Back to your scenario: when A is opened and fetches the first instance
of FOO, Rucksack will add a new FOO schema to A.  Afterwards, it will
run the UPDATE-PERSISTENT-OBJECT-FOR-REDEFINED-CLASS (is that a new
long name record?) function whenever A fetches an instance of FOO.

When B is opened, Rucksack compares B's most recent FOO schema to
the current class definition in the program.  In your scenario, the
schema probably doesn't differ from the class definition, so B doesn't
need to create a new schema.  Whenever B fetches an instance of FOO,
it just creates a FOO according to the current class definition; it
doesn't need to run UPDATE-PERSISTENT-OBJECT-FOR-REDEFINED-CLASS.

So all in-memory instances of FOO will always match the class definition
that comes from your program.  And rucksacks don't need to know about
each other.

Does that sound reasonable, or am I missing something?

> The only way to avoid that seems to prohibit the redefinition of class
> unless all interested Rucksacks are open

I hope I've shown that this prohibition is not necessary.

>> By the way: something that I *would* like to do sooner or later
>> (probably later ;-)) is to have distributed rucksacks: one rucksack
>> distributed over more than one machine.
>
> Cool stuff! So you'd be effectively building a distributed object
> system on top of Rucksack?

That would be the idea.  But I haven't though about this in any detail
yet, so I'm not sure that Rucksack's current design would actually allow
for this.

Arthur