Re: [Gzz] Serializing enfilades

[b . fallenstein]

> > [I simply think that serializing an object shouldn't save.]
> 
> Well, true, but OTOH what if we consider TransientTextScroll to be just
> a kind of a cache? So that saving the current contents would never
> really make any difference? Define the interface in such a way.
> 
> > Do note that the SpanMaker must be updated at this point to use a new
> > TransientTextScroll...
> 
> No, read what I said above: making TransientTextScroll synch transparently
> when desired. That might be the angle we want.
> 
> At least, I have a good feeling about that.

(Note: That means that this class wouldn't represent exactly one Mediaserver
block, but may represent more than one-- each time we save, one is added.
Not that I'd consider that a problem, but we might want to use another name.)

Hm. It sounds ok. There's one problem I can think of, namely that we could
save too often, creating a great lot of truly small blocks (e.g. one per
keystroke). If we specify the interface without explicit saving, API users 
aren't
required to think about it. Just thought about one scenario: What if someone
puts in a debug printout statement that gives the global identity of the
created span after each keypress? Or, worse, send the span through an RMI
interface? While our interface could explicitly state that getting the global id
saves, in the case of RMI serialization the blame for creating the small blocks
is on us (because we behave against the assumption you can make about a
Serializable object).

That considered, I don't like the proposal.

> > That would be a good point for that
> > method-- for which 'saveScrolls()' or 'saveAllScrolls()' would be a
> > better name, I think. Sound ok?
> 
> That 

Hm?

> > I will need to do something like this soon, because I want to start
> > experimenting with saving. It's not far off now.
> 
> Well, all the code is there basically ;)

Two main pieces are missing as far as I can see:
- Enfilade (span) serialization.
- Chaining Mediaserver blocks with serialized diffs, so that the
SliceVersion can be reconstructed.

The rest is almost finished now, I think. I'll commit sometime later today
(big commit, haven't hooked the other notebook to the net for some time now).
-b.