Re: [Gzz] Serializing enfilades

[b . fallenstein]

> > Saving the scrollblocks should be an explicit action, IMHO-- serializing
> > a serializable object IMO doesn't qualify for that (I'd expect it not to
> > modify any system state).
> > 
> > So what do we do?
> 
> The point of Enfilade1D being serializable is that you can then use it
> with the deltas transparently, without having all these horrible
> save and load methods everywhere.
>
> Maybe we should look at this from another angle: how about a transient
> text scroll that can at any time be asked for a permanent address, at 
> which point it syncs? I think that syncing when serializing an enfilade
> would not be too bad...

I simply think that serializing an object shouldn't save. I might want to
serialize it for reasons other than saving, and I wouldn't expect data to be
written anywhere because of that. (The problem is simply that the interface
would do something I wouldn't expect from it, which isn't nice.)

Do note that the SpanMaker must be updated at this point to use a new
TransientTextScroll...

> Or we could have a global synchScrolls method after which serializing
> enfilades would work, otherwise you'd get exceptions.

Yes, I like this basically. Though I don't feel good about it being truly
global-- there should be some context to this, so that e.g. there are no
strange interactions if two libraries in the same environment use gzz.media
independently without knowing about each other.

I guess there needs to be some context for spans anyway, because we need a
way to say "do load spans from this Mediaserver" (it would be bad architecture
[a major security hole eventually] if all parties would have to share the
Mediaserver they load span blocks from). That would be a good point for that
method-- for which 'saveScrolls()' or 'saveAllScrolls()' would be a better
name, I think. Sound ok?

I will need to do something like this soon, because I want to start
experimenting with saving. It's not far off now.

- Benja