Recorder Viewing

[Mark S. Miller <mark>]

Date: Fri, 20 Oct 89 10:04:57 PDT
   From: marcs (Marc Stiegler)

   Markm, dean, I have been assuming for a long time that one could
   see all the recorders attached to a document (assuming the permissions
   were set right). Dean tells me that this was a poor assumption, not be
   because it's impossible, but because it hasn't been thought through
   yet. Dean requested I post it, to remind him and alert markm.

I'm alerted.  I think the answer to this must be divided into two
parts: what the primitives are at the orgls & berts layer, and what
the interface probably should be at the docs & links layer.  I think
the answer at the orgls & berts layer is "no you can't see them", and
at the docs & links layer it's "sure, no problem".

To accomplish this, a docs & links layer referenced-recorder can be a
higher level construct consisting of a primitive (orgls & berts)
recorder and a link to the area on which the primitive recorder is
recording.  (A higher level hop-recorder would be similar, but would
link to the bert being monitored.)  Such a higher level recorder may
also specify link filtering criteria which are inexpressible at the
orgls & berts level.  Note that by using a link to remember where a
recorder is recording (and using an appropriate link type), posting a
recorder can ring other recorders on the same area, and all our tools
for typed link browsing and filtering can be used for recorder
management as well.

It remains to be proven that this configuration does everything it
needs to, and has no holes (such as security holes).

   There are two reasons why this excites me: 1) just to be able to
   see the recorders you have put on a document, so that you can
   delete them when you get tired of them (please see the picture
   of the Basic Document with Link Pane, wherein I have a sensor
   in the pane). 

Note that the primitive recorder is just a partial orgl being filled
in (informed) by the system instead of by another user.  If you buy
the notion of DataThingies (which Dean & I still have to resolve),
then the DataStamp of the partiallity is owned by the system and
always grabbed with a Foot.  By having the only user-visible
manifestation of primitive recorders be their read-only orgl end, then
we can garbage collect the recorder when we can garbage collect all
orgls that refer to that partiallity.  This way we can keep the
garbage collection and/or deletion of recorders completely out of the
orgls & berts semantics.  Note that if primitive recorders were
visible and manipulable, we would have to define 1) what they look
like, 2) a permissions system on their manipulation, 3) possibly a
grabbing operation to get mutual exclusion, 4) a semantics of garbage
collectability and/or deletion.  The reason they wouldn't just be
transparently garbage collectable is that you'd be able to find them
from where they're posted, and so wouldn't be garbage as long as the
material they're monitoring wasn't.  By having them be create&pull
only, we can just use the already defined orgl garbage collection
semantics.

   2) I really see the visibility of recorders as being a great support
   for spontaneously conferences: the authors of the recorders on the
   conference document are the participants, so you can quickly see if 
   there is anyone missing who should be there, for example (of course,
   if you didn't want anyone to know you were listening to the conference,
   you make your recorder private).

As far as I can tell, by having the above notion of higher level
recorders in the docs&links layer, you can do everything that you need
quite well.  And acheive this largely by reusing tools that we'll be
building anyway.

   We can build a system good enough to be wonderful without this support
   for evolving conferences, and we can probably figure out another 
   mechanism for solving the problem with seeing where you planted
   your
   recorders, but this seems like a natural way of doing it.

   Will it be a problem?

My solving this problem with a higher level docs&links layer construct
probably corresponds to "figure[ing] out another mechanism for solving
the problem with seeing where you planted your recorders".  Does this
other mechanism now seem natural to you too?