Re: [zzdev] Nile

[Tuomas Lukka <lukka@xxxxxxxxxx>]

On Mon, Dec 11, 2000 at 01:36:06AM +0100, Benjamin Fallenstein wrote:
> Tuomas Lukka wrote:
> > > Oops, of course. I completely forgot about that. (They're not more than
> > > an intermediate, though: you can't see where something came from, just
> > > all other places where it is. But that might suffice for the moment.)
> > 
> > Hmm, isn't that the whole point of transclusions?
> 
> No? You want to be able to see where a quotation is from, for example?
> (Or, follow the way back some text went through your document?)

Well, that would be a kind of a Xanadu link on the global level, I'd guess.

> Well, to get the thing usable, we could start with jumping between the
> different occurences of a single character -- that would save us the
> headache of span overlap for the moment.

Still... I'd rather do it properly.

> > > So, a spacepart which deducts the substream from the two markers?
> > 
> > That's certainly possible. Still have to think about it for a while.
> > 
> > The basic question is, I think, whether we really want to duplicate those
> > cells in the structure or have a real, simple, unmodifiable reference in the
> > place where the stuff was included in. Because that way the structure of
> > copies would be clearer to the user.
> 
> If we have a spacepart which interprets the reference, we still have the
> plain structure which is interpreted by the spacepart. I think we want
> to be able to view both.

The problem with spaceparts here is that currently they can't work on dimensions
that are not their own.

I don't know, something just makes me feel uncomfortable about this idea but 
I can't yet think what. I'll try.

> > > Hmmm... does that mean the d.n dimensions would be shown with
> > > vanishing-like views in this context? I.e., you could seamlessly
> > > integrate d.n connections with Nile streams etc.?
> > 
> > What is d.n?
> 
> d.1, d.2, d.3, d.4, d.5...

Why not. It sounds like a very nice way of connecting cell-level and nile.

> > > > Ok, except for terminology we are along the same lines here. Except
> > > > that the applitudes will not use ZObs, but rather, simply have their
> > > > own dimensions which are associated to that applitude somewhere else.
> > >
> > > Again, I fear we're running into namespace problems here. Any plans on
> > > how to prevent that?
> > 
> > well, by having dimensions be cells and the dimensions used in a particular
> > applitude would then be in that applitude's definition.
> > 
> > ZigZag and structure means that we don't really need to use naming anywhere.
> > OTOH, having names is very convenient for humans...
> 
> If we use cells as dimensions, of course. Do you already have solutions
> for the obvious problems? :)

Which are the obvious problems?

> But I really like this version better. E.g. because it means dimensions
> can have different names in different languages.
> 
> (Which brings me to i18n... ugh, I really have to tackle that sometime soon)

It is a nasty one.

> > > > Now the question remains of whether it's possible to make it efficient.
> > >
> > > Hm -- should be, because a cell could know the applitudes it belongs to,
> > > by checking its connections on the respective dimensions while being loaded.
> > 
> > A cell can be in several applitudes.
> > 
> > If I have an anchor in the text that I've connected to one applitude and connect
> > it to another, that would have to be noted somewhere.
> 
> That's why I used plural for "applitudes." ;o) And when you connect a
> cell in a different applitude, that's noted in the cell object.
> 
> Or do you think that'd cost us too much memory?

Memory, performance, cleanliness.

Remember that cells are supposed to be disposable handle objects.
We should know which cells we do want these markings for and which not.

The thing is that we have a sparse array here: cells and dimensions. We currently
index that array only so that for each dimension you can see which cells are connected.
Doing it the other way around too is possible but opens up other problems, like
spaceparts(!). Because we can't cache that info for spaceparts, we'd always have to
ask them.

Hmm, this begins to seems a bit troublesome.


	Tuomas