Re: [Gzz] Serializing enfilades

[Tuomas Lukka]

On Fri, Jul 26, 2002 at 11:36:50PM +0200, address@hidden wrote:
> > > 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.)

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.

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

That 

> 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 ;)

        Tuomas