[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: [zzdev] Re: [zzdev] versioning & cell copying
- To: Benjamin Fallenstein <b.fallenstein@xxxxxx>
- Subject: Re: [zzdev] Re: [zzdev] Re: [zzdev] versioning & cell copying
- From: Tuomas Lukka <lukka@xxxxxxxxxx>
- Date: Fri, 8 Sep 2000 15:30:33 +0300 (EETDST)
- Cc: zzdev@xxxxxxxxxx
- In-reply-to: <39AFF0E6.BB45595@xxxxxx>
On Fri, 1 Sep 2000, Benjamin Fallenstein wrote:
> Tuomas Lukka wrote:
> > Very good cases - I'll have to talk about these with Ted. Having solid
> > examples makes things so much easier to talk about. Yes, now I see why
> > sending a cluster of cells makes a lot of sense..
> Recent realization: We can and should have both in one. If we want to
> send a bunch of cells, first we pull them out into a slice (i.e.
> transcopy them), then we send the slice. When we get a slice back with
> modified versions of these cells, we can integrate it into our normal
> space by transcopying them instead of just attaching the slice. And then
> we can use our usual versioning tools.
> Why we should generally transcopy cells into slices? Because when we
> *can* store identity, why the hell shouldn't we? I mean, the reasons
> really are the same as the ones because of which we want transcopying
> for fluid media (i.e., the xu system). We do already have the primitive
> SlicedSame stuff; why shouldn't we extend this so that we can really
> maintain identity?
I was talking about this with Ted: he called the things to send and
receive "bunches" instead of slices which are larger. The idea would
be that the bunch has a list of cells (like a mark) and when one is
received, that has some of the same cells as we have, then the original
cells are not touched.
The big problem is making clones etc. work the right way: sometimes we
want clones to unify and sometimes not: for example, when we change the
definition of a clang routine in the root clone.