Early morning musings

[fowler]

For some strange reason, I woke up at 5 am this morning with a bunch
of bizarre ideas about what we were talking about last night.
Amazingly enough, I still remember them and they still make sense,
although not at first glance.  Here they are:

On closer examination, I don't think that using the level of recursion
to decide when to output the interest information will work without a
lot of overhead.  For example, if you had two functions called (top)
and (bottom), with (top) calling (bottom).  Now imagine two modules
called foo and bar.  foo registers interest in (top) and (bottom) while (bar)
registers interest only in (bottom).  If geomview calls (top),
interest data must be sent to foo while geomview is in (top) but not
when it enters (bottom).  However, data must be sent to bar while in
(bottom) since it did not receive the data when geomview was in (top).
I think the only way to get the level of recursion thing to work would
be to remember at every step what the last level where interest data
had been output was for every single pipe.

There seem to be two sorts of cascading - the horizontal sort and the
vertical sort.  Functions calling other lisp functions is the vertical
sort and functions causing other lisp functions to be called after the
original function has terminated is the horizontal sort.  The
xform-set command leading to clicks seems like the horizontal sort.
At least as far as journaling, I don't think this is that big a
problem.  I thought of creating two kinds of clicks - a timed click
and a forced click.  Timed clicks would be the result of xform-set
commands and the journal thing would not register interest in them
since recording the orginal xform-set command would be sufficient to
recreate what was going on.  It would register interest in the forced
click commands (sent to geomview from modules).

I came up with a rather strange solution for the vertical cascading
problem.  It takes advantage of the fact that when an external module
(or geomview itself) sets up the lisp parsar for a command, for
example:
  LDECLARE(("pick", lake, args,
            LARG_STRING, &name,
            LARG_HOLD, LARG_FLOAT_ARRAY, inter, &in,
            LARG_HOLD, LARG_FLOAT_ARRAY, v, &vn,
            LARG_HOLD, LARG_FLOAT_ARRAY, e, &en,
            LARG_END));
the parsar does not really mind if more arguements appear than are
asked for in the declaration.  So it seems like a function set up to
take something like 
	(pick Item (x1 y1 z1))
would work without mistakes or error messages if it received the
function that came through the pipe actually said,
	(pick thingy (.1 .1 .1) (.2 .2 .2 .3 .3 .3))
I'm not sure if this is a bug or a feature, but hopefully it will stay
around.  Likewise, a function meant to take 
	(top x y z)
would not care if it got 
	(top .1 .1 .1 (bottom 5))
So in the geomview code (or whereever the functions were actually
implemented) each function would look through its interest list and
send the following to all of the interested parties:
	([function name] [arguements]
without a ) at the end.  It would then do whatever needed to be done,
possibly causing further interest things to be output, but since they
would be inside the original set of ()'s, they would generally be
ignored.  If a program were really nosy, it could probably concoct
some scheme to parse them, but it usually wouldn't want to.  Right as
the function was about to return, it would send to ) to everything
that had received the original message.

I know this all may sound a bit incoherent, so here's an example:
(top) and (bottom) are geomview functions, with (top) calling
(bottom).
foo, bar, and bat are external modules.
foo registers interest in (top) and (bottom)
bar registers interest in (top)
bat registers interest in (bottom)
When (top) is called, foo will receive:
	(top [top's arguements] (bottom [bottom's arguements]))
bar will receive:
	(top [top's arguements])
bat will receive:
	(bottom [bottom's arguements])
When (bottom) is called, foo will receive:
	(bottom [bottom's arguements])
bar will receive nothing, and bat will receive:
	(bottom [bottom's arguements])

I think this might work a better than various other hacks.  There is
no way a single command could cause an interested party to receive two
independent commands, which was the real problem in the first place.
For journaling, one of the main worries was that the script would be
filled with large quantities of low-level or meaningless junk.  This
would not happen in this case since whatever would do the journaling
would register interest in practically everything, parse the
arguements to each function and ignore the list of lower-level
functions which the function called, and spit the function name and
the parameters to the script file, eliminating all the info about the
low-level function calls along the way.  I actually think journaling
might work better as an external module if it worked in this way.  

Another worry is that there would be an unacceptable amount of
extraneous garbage being generated.  I don't think this is that big a
deal; there would be exactely the same number of characters being sent
to each external module as there are now.  It might make sense to try
to keep the amount of stuff generated by the interest statments as low
as possible, but that's another problem...

The lisp parsar would have to be slightly changed, but I don't think
it would be that horrendous.  Each function would have to call some
interest routine at the start and end of every function, but this
still does not seem like that big a deal.  I also think doing things
this way would be much easier to maintain in the next few months/years
than an intelligent journaling mechanism, a level of recursion
variable, or some division between high and low level functions.

As a continuation of my early morning musings, I cannot resist
putting in an advertisement for my favorite hinted-at-but-not-written
lisp command.  The problem with the two cameras for the stereoscopic
view getting in lock step could be solved if you could register
inteerest only in the targetcam and then send everything that it did
to the not targetcam.  The only problem is there is no word to refer
to the not targetcam.  A while ago I was daydreaming about two
functions:  one which would return a list of the objects in the world
and another that would return the actual name of the target geom.
If this two functions could be implemented and extended to work on
cameras, I think the problem would be solvable since there would be an
easy way to talk to the not targetcam.

Ok - that's it.  Thank you, gentle reader - I know that was pretty
long-winded (just be grateful I didn't start calling everybody when
I first thought about this).  Anybody have any thoughts?

-Celeste