gzz-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Slicer (was: Re: [Gzz] Re: [Gzz-commits] (no subject))


From: B. Fallenstein
Subject: Re: Slicer (was: Re: [Gzz] Re: [Gzz-commits] (no subject))
Date: Wed, 31 Jul 2002 19:59:44 +0200

On Monday 29 July 2002 21:13, Tuomas Lukka wrote:
> > Huh? Swapping slices in and out are not frontend functions?
>
> It's just like saving and loading the whole space etc: it belongs
> in the control package. Gzz is for the structure, not concerned with
> whatever's underneath.

Hm-- had to think about this a bit. I'd always somehow assumed the ideal is 
that everything can be done through the gzz interface, except maybe 
bootstrapping the initial Space object...

> I don't think our slices are mature enough to expose there as
> the "canonical interface".

It's just an interface, not an implementation-- and it's a minimum of 
functionality, I'd think... but...

I think the real question here is whether we see Space as a singular entity 
that can internally be composed of slices, or a composite that may support no 
more than a single slice.

The problem with the former approach is: you cannot cleanly separate the 
Space from your saving functionality. When you know about Slicer, you can 
have a separate Saver or something object that stores SliceVersions on the 
disk-- POSSIBLY serialized and POSSIBLY in mediaserver, but not necessarily. 
For example, we could create saving/loading modules for Les' XML 
representation and for our old file formats-- both quite desirable.

When you don't know about Slicer, you cannot do this; if you save a composite 
space as if it were a single slice, you're in for havoc. OTOH, when you save 
a single space and save it as if it were a composite containing a single 
slice, no problem.

But you're right, it's relatively experimental *and* for a good part a 
control module issue.

So, let's make an own package for it, with its own subclass of Space, and 
explicitly encourage implementors to use it even if their implementation is 
single-sliced-- advise them to simply use a SingleSlicer or similar, because 
of the interoperability they gain when they can be saved in the same way.

Ok? gzz.slices and gzz.slices.SliceSpace? And gzz.impl implements that 
interface?

- Benja



reply via email to

[Prev in Thread] Current Thread [Next in Thread]