[rucksack-devel] Re: Rucksack, ECLM

[Nikodemus Siivola]

"Arthur Lemmens" <alemmens at xs4all.nl> writes:

> Actually, I think this is not OK so far.  I think you shouldn't
> MAKE-INSTANCE a persistent object unless there is an open current-rucksack
> (which is created by WITH-RUCKSACK, or maybe by
> (SETF (CURRENT-RUCKSACK) (OPEN-RUCKSACK ...)).

Fair enough.

> We'd probably want a function like
>
> (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.)

>>      Is a single Rucksack a "universe" or a "container"?
>>
>>   If a Rucksack is a universe, then it would make sense to enforce
>>   certain restrictions on that universe: eg. you cannot assign objects
>>   belonging to other universes to persistent slots.
>
> Yes, that's what I have in mind.  I do think that it should be possible
> to work with multiple rucksacks at the same time, but I think there
> shouldn't be persistent connections between rucksacks.  You *can* have

Right. This gets back to the question of identity: universe (rucksack)
is what desides whether A bleeds when B is cut.

>>   In the universe case there is a relatively simple option that might
>>   untangle some things: make Rucksack a property of a class.

> Hehe.  Interesting idea.  But then you can't migrate or copy objects
> between rucksacks anymore, can you?

It would be mildly tricky at least. ;-)

But the class still needs to at least know to which Rucksacks its
instances belong: otherwise it cannot update schemas of multiple
rucksacks when it is redefined. ...and then you have another nightmare
scenario:

 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.

Which definition of FOO is in effect? Which instances are updated and when?

If this is something that users should not do, then the Rucksack seems to
me to effectively be a property of the class already! 

The only way to avoid that seems to prohibit the redefinition of class
unless all interested Rucksacks are open... which will then require
that Rucksacks know about each other, so that the requirement can be
propagated to the next session.

> Interesting questions, these.  I'm not saying that my answers are the
> best ones, I'm just explaining what I had in mind for Rucksack.  If you
> think that another approach would work better, please let me know.

The reason to all this pestering is mostly to find out what you have in mind. ;-)

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

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."