[Top][All Lists]
[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
[Gzz] Re: [Gzz-commits] (no subject), b . fallenstein, 2002/07/29