Re: [zzdev] Nile

[Tuomas Lukka <lukka@xxxxxxxxxx>]

On Sun, Dec 10, 2000 at 08:48:46PM +0100, Benjamin Fallenstein wrote:
> Tuomas Lukka wrote:
> > On Sun, Dec 10, 2000 at 04:46:31PM +0100, Benjamin Fallenstein wrote:
> > > The one thing I would like to see soon is cloning (and once we have
> > > versioning&pull-outs, transcopying) of part of a Nile stream.
> > 
> > By cloning, do you mean active or passive copies? This might be easiest
> > handled by a mechanism like below where it's not copied but rather
> > used as an object inclusion from the other place.
> 
> Active copies, i.e. when you change the copy, the original changes. I'd
> call passive copies transclusions if you can follow them back, and
> copies if you can't. (Transclusions we should probably postpone until we
> have general versioning, because we can build on the unified basis then,
> and copies are trivial.)

Umm, transclusions already work, at least on the fluid media level, in 
the TextCloud demo. To make them work in Nile on that level is a 15-minute
job, approximately.

Transclusion of the structured stuff is a whole different question
altogether...

> > But this has problems with placing the cursor...
> > 
> > So far, all our views are nonhysteretic, i.e. given the cursor location,
> > dimensions and parameters the result is always the same. Placing the
> > cursor on some other part of the text would jump there and going back
> > would be difficult. This opens an interesting can of worms...
> 
> I've tried to address them back in my "thing" draft from June or July
> with a cascading (recursive) cursor mechanism. However, we might be able
> to get away more easily here if we let the cursor point to the cell
> which represents the substream (aka handle), and interpret the cursor
> offset relative to the substream (cursor offset 8 means the 8th
> character in the substream). This doesn't get out of bounds if we
> introduce a spacepart that actually takes the whole content of the
> substream and makes it the content of the handle.

Doesn't work properly with paragraph-level stuff.

> Or we could make a spacepart that actually mirrors the substream in the
> superstream (then we'd need to use a dimension from that subpart for the nile2iters).

Yes, a multi-clone of the cells could well be the right way.

The problem is implementing those in a reasonable way, and that's not going to 
be easy. For example, extending the bounds of the included text...

Hmm, actually I start feeling that maybe a nile-specific mechanism *would* be
more appropriate as then you'd just move the marker cells to the right place
in the stream.

> > My first use for this will probably be two-directional anchored point-to-point
> > hyperlinks, showing the linked-to text as floating in the margins.
> > 
> > Probably putting a single alphanumeric character in the special cell
> > would make things easiest for the Nile2Iter&co...
> 
> That doesn't make a lot of sense to me. I think you should really use a
> model that looks along a special dimension if something's there, and if
> yes, we have a special cell. How the meaning of that cell is determined
> is another question -- that doesn't need to interest Nile2Iter (except
> if it's a subpart, i.e. not "one character long").

It does belong to the units in Nile2Unit and forcing them to worry about
it any more than they have to would create more complication all around the system.

> > Hmm, applitude-wise, it would be nice to be able to look for the special
> > code just by dimension, so we'd have one cell connected to the stream in the special dimension
> > and then that cell would be connected using a dimension that is special.
> > This is the way applitudes are supposed to work. I wonder whether we could
> > make it work already at this point?
> > 
> > The problem is that searching for which of N dimensions a cell is connected
> > along is an O(N) operation which is NOT nice when the number of applitudes grows.
> 
> It also doesn't seem to make sense to me: in that model, Nile would need
> to know all other applitudes that work with it. That's NOT the way
> applitudes are supposed to work, is it?

No, it wouldn't, actually. There'd be a global applitude table somewhere, or
applitudes would be connected to the dimensions.

Why would nile have to know what applitudes work with it --- applitudes work with
*every* other applitude, at least to some level. That's the whole point of them.

The idea is that the one cell, connected on d.nile-special to the stream can be *anything*.
*IF* it has a textual representation, we'll use it. If not, we'll just ask that applitude
to show it somehow somewhere nearby.

> > Any ideas?
> 
> I think if something from one applitude is included in something from
> another applitude, the best way to look at it conceptually is to see the
> connection as kind of a view. 

This has again the problem of hierarchy: how come it works just one way?
This is the paradigm of e.g. kparts, bonobo, OLE, OpenDoc and a whole
lot of others.

I'd prefer (and I think I understand Ted about this) it to be a connection,
not inclusion.

> The "master applitude" finds a cell which
> is "special." It somehow knows some code linked to that cell. (How that
> should work is another question; for the moment, the ZOb interface and
> similar structures work well.) It calls that code, which belongs to the
> "sub-applitude." The "sub-applitude" is given the special cell, and
> knows how to look for some of its own data from that cell. It reads that
> data and processes it, like a view. Then, it returns a "view" on that
> data in a form which the "master applitude" understands -- in the case
> of Nile, something like an FText.Part array. The "master applitude" goes
> on in building its own view.

I'd rather not call them "master" and "sub-applitude", since that's
conveying the wrong picture.

What we have is a bridge between two worlds, for instance a calendar and 
a text stream. The display code could be coming from either side - 
as a matter of fact, the idea would be for the applitude that reaches
that cell to basically send out a call "who'd like to show this cell
or connections to it" and the other applitudes jumping in and splatting
their views about it on the screen, with priorities obtained through
user preferences and other methods. 

This way, moving from between the text stream and the calendar could
be fluid.

> Of course there can be different "views" on the same data structure
> belonging to the "sub-applitude," meaning the data can be integrated in
> different data structures of different "master applitudes" in different
> ways at the same time.

Yes. It depends on where you come to it from. That's why I don't like "master".

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.

Now the question remains of whether it's possible to make it efficient.

	Tuomas