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

Applitude connectivity, was: Re: Spaceparts vs. first-class structures, was: Re: [Gzz] Summing up...

Tuomas Lukka wrote:


On Sat, Oct 05, 2002 at 05:36:45PM +0200, Benja Fallenstein wrote:

Ok, this is a more fundamental issue.


Definitely. Note, of course, that I'm really undecided on this issue
and therefore am playing the devil's advocate.
Ok. Sounds like this could become a really useful debate :-) (note to everybody: that was a cue for you to participate :) ) 

*snip*


I know. This is why we need to consider the alternatives carefully.
Some ZZ structures which are interpreted by a program seem to be surprisingly fragile, and sometimes difficult to change with the general utilities. 


What exactly are you refering to? And why difficult to change?
Putting each character in its own cell (the vstreamdim approach) was a big mistake because the optimizations intended to make it work never worked correctly. But that doesn't seem to be what you're refering to. What is it? 

Basically, any interaction between two structure. Can we really have
a situation where different applitudes' data shares cells and have it
really work?

I'd really love it if you can convince me on this.
Ok, now I understand better. Let me see. (I had to think about this for some time.) 

Let's assume we have:
- an IDE that allows structuring code in interesting ways, allowing connection of methods etc. - a task planning tool like Ted has been talking about: lists of tasks with dependencies and a "now line" that seperates what's done from what's next and after. 
- an email client.
- a scheduler.
- an annoying daemon that alerts the user on appointments.
All of these have been developed independently, but the scheduler, the email client and the appointment daemon have agreed on a common format for representing dates. Unfortunately, though, the scheduler and the daemon use different structures for representing appointments (there has not been coordination, as there cannot always be). Everything is programmed in a modular fashion. Also, all the applitudes have been designed carefully so that unanticipated connections will be possible, as far as is feasible. (We're assuming the ideal case w.r.t. the design of the individual applitudes, but a not-quite-ideal case w.r.t. the coordination between developers.) Now let's see what we can make of this.
We'd like to stitch these together into kind of a software project management applitude. (Note, btw, how we *can* say we're creating a new applitude here: the desired result is a "zone of functionality" not walled off from the rest of the system, an activity that you might want to do by itself for some time or that is easier to explain by itself). We'd like to manage tasks in code development using the task planning tool and because that tool is just about dependencies, we'd like to use the scheduler for doing deadlines, and the appointment daemon to remind us when a deadline for some functionality approaches. (We'll be subverting the normal purpose of the daemon somewhat in that we'll make it remind us days or weeks instead of minutes or hours before the deadline. Its programmers were clever enough to make this configurable, even though they did not think of *this* use.)
So, let's start by putting programming tasks in the task planning tool (see btw <http://xanadu.com.au/zigzag/manual/zigzag31.gif> for a graphical rendering of it). These are like, "Write class X," "refactor class Y," "document package Z," "redesign aspect A of classes B,C,D" and so forth (i.e., they're relatively close to the code). -- When creating the tasks, we want them to show up as cells like "Refactor class Y," with some paragraphs of explanation below if we choose a view that shows more of the cell. Now, of course, we want that cell to be bidirectionally connected to the class itself. Ok, we use some general linking mechanism. This link works as long as both cells are there-- the task and the class; if one of them is deleted, the link doesn't work anymore. Can this happen accidentally because of the way either applitude treats its structure? If the task is deleted, that probably means that the user decided it was a mistake (or that it's done, but I for one wouldn't delete done tasks). In that case, it's fine if the link disappears. If the class is deleted, that can mean that it's gone or that it was renamed, BUT if the IDE application is programmed sanely it will NOT use a different cell if the user requests renaming the class, so let's assume it means the class is really gone. Well, duh-- the link doesn't make much sense then either. (Neither does the task, but that's the user's problem.) If the user splits the class in two parts, there's also not much we can do-- if they do it by creating a new cell and moving some of the stuff in the class there, the link will stay with the old class, it's the user's responsibility to change it if that's the right thing to do. All not terribly new or exciting.
So now, we have those tasks that are in a dependency structure. Each task is a single cell, and the dep. structure is on two specific dimensions. Now enter the scheduler. It allows us to schedule appointments-- that is, assign dates and times to them. Each appointment is a cell, each date/time is a cell, and they're paired along one dimension. Date/times are connected on a long chronological line along another dimension, and related appointments are also connected chronologically along that dimension. (Not the best structure for this task, probably, but I don't want to think too deeply about this now...) The applitude features a spiral view of time, such as Ted has been advocating as an example for non-paper design somewhere (it's a spiraled timeline, where you can change a view parameter to set the time corresponding to one round in the spiral-- an hour, a day, a week and so on). On the spiral, it shows the appointment cells near the time of the appointment. Very nice.
What we do, of course, is appointment = task in the dependency structure (same cell). We enter the deadline for that task as the date of an "appointment."
Now (assuming an advanced Gzz...) we can open two views side-by-side: the task dependency view (possibly vanilla zz view with special treatment of vinks, or some other more-or-less general view that fits well with this task) and the time spiral, and toggle a view option that helps us seeing what is what (possibly procedural textures or some form of lines between instances of the same cell). This view can be of great help when planning/scheduling. We can drag-and-drop tasks to different places on the spiral to (re-)schedule them: that's a feature that the scheduling applitude offers.
What we do *not* have is a view showing automatically when we have a dependency conflict, i.e. scheduled a task before another task it depends on-- this is a new view option that flows from the combination of the two applitudes. If the user is an absolute non-programmer, they'll live without it. If they know some programming, they should be able to easily write a one-liner or almost-one-liner that colors a task bright red or some such the moment a dependency is in conflict (while dragging the task into place in the scheduling view). If we have this, we can drop the task, having the conflict, then click on it to focus it in the dependency view, look at the dependencies and decide whether to reschedule them (or break the dependency relationship, if appropriate).
[As Ted says in the Floating World docs: The system does not include these views, but functionality with which they're easily set up.]
Now note what we have archieved: now, when we look at class Y in the IDE, we automatically see the task connected to it, and if we have a view that shows that much focus, we also see what other tasks it depends on and when it is expected to be done. This could be quite helpful when reading/editing that class.
Bringing in the alert daemon, it has unfortunately a different structure for storing the appointments: two other dimensions, one for appointment/datetime pairs and one for connecting the appointments that we want an alarm on. As a third cell on the rank with the appointment/date pair, we can specify how long in advance we want to be notified of the event. The dates are not connected.
Now there are two possibilities to combine this with the scheduler applitude. If we know some programming, we can step into the alarm daemon code; as it is terribly modular and the code is extremely well designed, it's trivial to change the structure used in one central place, so that it can use the structure of the scheduling applitude. If we don't know programming, we can still add the deadlines in the daemon's structure. *Because the applitudes are sharing the date cells*, rescheduling works: the date changes, and the alarm daemon uses the same date format and the same date cell, so everything goes fine. Breaking the connection between date and task doesn't work out so nicely: we have the redundant connection, so you need to break it in both dimensions, or you'll get superfluous annoying alarms. ;-)
Finally entering the email client, I'll skip over the details, but we can additionally: 
- make links between the code and emails that discuss it
- set up replying to specific emails as tasks
- set up discussing specific tasks per email as dependencies of those tasks
Because we share the date format with the scheduler and alarm daemon, we can with somewhat more effort probably also: 
- use the scheduler's time spiral view to show received email
- view received emails and pending tasks on a single time spiral
- do 'reverse alarms': if I haven't replied to an email a few days after receiving it, notify me 

These may require a little programming to stitch things together.
All this isn't so terribly deep sharing of internal cells between applitudes. The sharing is quite shallow; the 'deepest' data sharing is the date cells, which only works because dates are stored in a previously agreed-upon format. BUT, this *is* an example of sharing that is both highly desirable and impossible in classical computer environments IMHO, possible because all data is stored in zzstructure.
(In many ways, it's the unix philosophy: many small tools using a set of simple interfaces that allow them to be combined in powerful ways.)
Certainly the project hasn't been emphasizing the point of using structure directly enough-- there's been this bias that 'applitude' means 'views and bindings that hide the structure.' But turning 180? and saying that structure interpreted by programs is bad or not important is just as wrong. 

I'm not saying it's bad. I'm just afraid of all the difficulties
when there are several programs using the same cells from orthogonal
points of views.

The potential interactions between the programs are very complex
and it'd be easy to get undesirable emergent behaviour (oh, because
this applitude wanted to insert a linebreak here, it split this cell,
and because of that, this other applitude didn't see that half of the
text and the xanadu link there any more etc etc etc).

This is the one part which Ted never talks about: there are all these
clever and simple things that can be done with the structure, but once
these simple things are combined, really bad complexities can emerge. 

Yes. Ok. -- I think the lessons I would draw from the thinking above are:
- We need simple and clear protocols for sharing between applitudes that are agreed upon. The simplest of these is sharing a single cell representing one concept in two structures-- examples: the task/appointment of above, a person in address book and birthday book and genealogy and email client, etc. More difficult is if the data in a cell or plex of cells (defined by a maincell) is also shared somehow, for example the date in the example above.
- Data sharing between applitudes isn't going to be terribly "deep" in the sense of large and complicated data being shared, probably. It's likely going to be mostly cells (identity of concepts) and some easy types useful in many different contexts (such as dates). You could say that the pattern for the latter one is: Someone defines a fundamental structure (e.g., for representing dates), possibly as part of a larger applitude, and other applitudes start to use the same structure when representing the same kind of data. This isn't magic, just simple agreement on standards, but the point is that by using zzstructure, actually sharing these objects between applitudes is possible at a very low level (with the result that if one applitude changes the contents of the cell or plex of cells-- the date, here-- the change will be reflected in the other applitude(s) using the same cell(s)).
- Combination of applitudes isn't automatic, but needs a human in the loop who spots the possibilities for combining applitudes and carries them out (to create a new applitude). Or, sometimes it may happen implicitly when a human decides to use a plex created in one applitude as data in another applitude using the same format-- again dates being the example from above, i.e. for example cloning a date into another applitude and having it updated when it changes in either applitude. (Of course, again this rests on a clear and agreed-upon definition of the semantics of the date structure and how to change it.) In any case, it's not magic, it happens when humans do it.
- Often, combination of applitudes will involve data sharing, but at least just as often it will not-- only making links (which is, though, data sharing with the general-purpose link structure). Still, this works only if the applitudes have a cell for each item that is important to a human-- i.e., it is a property made possible by zzstructure.
Arguably, making links is making "human structure," because it doesn't mean real cooperation between the applitudes involved. Still, even for that, it is necessary that the data is stored in zzstructure, because only this allows building the "human structure" of links-- zz links need cells representing concepts (items) at their endpoints.
The idea of zzstructure is that all activities around the computer take place in the same structure, allowing interconnections and overlap between *everything*, human-interpreted or program-interpreted. 

Exactly. My question (which I haven't been able to formulate as clearly
earlier) is whether we can handle the ensuing complexity.
After this thought experiment more strongly than before, I think that the key is to clearly define structures used by multiple applitudes (including what behavior is expected for changing the structure), and then allow users to exploit the combinability of applitudes that ensues. The users are mostly responsible for conflicts-- they should be informed of the behavior of each applitude's bindings and have to determine themselves whether there'll be conflicts. (Which doesn't mean that we need good tools to recover from problems, just that it's a strong AI task to determine whether what the user does is reasonable ;) ) 


Also, note again that my true views are somewhere between what you say
and what I say here; I also hope for great things but here I present the fears.
Yes, I understand completely; I've had similar thoughts. This email from you was much of a relief from me, because your last email before that sounded to me like, "maybe zzstructure for everything is not such a good idea, let's keep it on the surface as an interface but store the real data in conventional data structures," which made me go, "argh, why're we working on this project?!?". Now I understand much better, because I've also pondered the problem, "how can applitudes *really* work together which are not just zz connections interpreted by humans?" (In fact, this was the cause for my 'thing' draft >2 yrs ago, and after Ted's reservations about it, I tried to express these concerns to him [http://www.xanadu.com.au/mail/zzdev/msg00397.html]. Anyhow, nowadays I would say the combinatorial approach of that idea-- build new objects/"things" out of other ones-- isn't so great in the general case; it's *one* thing we need, for example to embed a formula into some text or into a figure etc., but it's not the most exciting part about zz applitude interconnectivity. I like the thought experiment example above better ;-) ) 

- Benja