Re: [Gzz] Serializing enfilades

[Tuomas Lukka]

> (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.)

Certainly

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

For RMI, and others, we can always create serializers that work differently:
Java allows you to customize serialization. 

These are small complications compared to the simplicity obtained from the 
serialization.
Printing the global identity of the span in a printout is actually not terribly
easy: you can print the span object but that wouldn't serialize it --> no 
saving.

I don't think that these would really be such problems...

Another possibility would be to give the scrollblock a temporary GUID (as a 
RandomNameSpace
name), and then provide a mapping with the stream...

        Tuomas