TorchesDiscussion.mail
	 1-Mar-90	Pavel Curtis	Torches Discussion
Date: 01 Mar 90 10:35:52 PST
Sender: Pavel Curtis:PARC:xerox
Subject: Torches Discussion
To: PCedarImplementors:PARC:Xerox

Currently, the torch service consists of the four commands TakeTorch,
GiveTorch, StealTorch, and TorchTaken?, described in
/PCedar/Documentation/DFDoc.tioga.  The commands run only in PCedar, but
can be used to control packages in PCedar, Cedar7.0, CedarChest7.0, etc.

Just to get things started again, I propose that use of these commands
be mandated for all packages on PCedar, without exception.

It has been suggested that BringOver and SModel issue warnings if the
package being manipulated is on PCedar and the current user does not
hold the torch for that package.  I support this idea.

It has also been suggested that these commands be implemented in DCedar
as well.  I support this idea, too.

Let the discussion (re)commence.

	Pavel
	 1-Mar-90	Christian P Jacobi	Re: Torches Discussion
Date: Thu, 01 Mar 90 11:52:19 PST
In-reply-to: "Pavel Curtis:PARC:xerox's message of 01 Mar 90 10:35:52 PST"
Sender: Christian P Jacobi:PARC:Xerox
Subject: Re: Torches Discussion
To: Pavel Curtis:PARC:xerox
Cc: PCedarImplementors:PARC:Xerox

1) I think torches are a good idea and long overdue.

2) I am absolutely against declaring a feature mandatory before it is not implemented and tested.

3) Torches is a technical solution and needs a description of the problem it solves.  E.g. once we have torches could everybodys summer intern take the torch of Rope.mesa and change it? What are the rules?

Christian
   
	 1-Mar-90	To: Pavel Curtis	Re: Torches Discussion
Date: 01 Mar 90 12:30:03 PST
In-reply-to: "Pavel Curtis:PARC:xerox's message of 01 Mar 90 10:35:52 PST"
Sender: Kenneth A Pier:PARC:Xerox
Subject: Re: Torches Discussion
To: Pavel Curtis:PARC:xerox
Cc: PCedarImplementors:PARC:Xerox

Confusing (to me) discussion occured earlier about the granularity of
torches.  It looks like a torch is defined by a -Suite.df existing for a
package for which one can manipulate a torch.  True? Are there other
options currently implemented?
	 1-Mar-90	Mike Spreitzer	Re: Torches Discussion
Date: Thu, 01 Mar 90 12:39:09 PST
In-reply-to: "Pavel Curtis:PARC:xerox's message of 01 Mar 90 10:35:52 PST"
Sender: Mike Spreitzer:PARC:Xerox
Subject: Re: Torches Discussion
To: Pavel Curtis:PARC:xerox
Cc: PCedarImplementors:PARC:Xerox

There should be a way to ask for a list of all the torches I hold.  I know I can get this by filtering the already-gettable list of all torches held by anyone, but I shouldn't have to do the filtering, nor even write a program to do the filtering.
	 1-Mar-90	Christian P Jacobi	Re: Torches Discussion
Date: Thu, 01 Mar 90 12:44:34 PST
In-reply-to: "Christian P Jacobi:PARC:Xerox's message of Thu, 01 Mar 90 11:52:19 PST"
Sender: Christian P Jacobi:PARC:Xerox
Subject: Re: Torches Discussion
To: Christian P Jacobi:PARC:Xerox
Cc: Pavel Curtis:PARC:xerox, PCedarImplementors:PARC:Xerox

About granularity:
	I vote for using the short name.  Separating torches for DCedar and PCedar will cause me to frequently use the wrong torch.   Anyway DCedar and PCedar developpment should not digress too far, and, if it does those implementors might consider sharing a torch and use a fine grain mechanism between them.
Christian
	 1-Mar-90	Tim Diebert	Re: Torches Discussion
Date: Thu, 01 Mar 90 13:00:51 PST
In-reply-to: "Pavel Curtis:PARC:xerox's message of 01 Mar 90 10:35:52 PST"
Sender: Tim Diebert:PARC:xerox
Subject: Re: Torches Discussion
To: Pavel Curtis:PARC:xerox
Cc: PCedarImplementors:PARC:Xerox

We need to be very careful about mandating things for PCedar without
remembering that PCedar lives in places other than Palo Alto.  In some
case there is TCP/IP service to these places and others only have XNS. 
Personally I think torches are a wonderful idea.  How to implement them
to be useful all over the Corporation is another mater.

Tim
	 1-Mar-90	Michael Plass	Re: Torches Discussion
Date: 01 Mar 90 17:19:11 PST
Sender: Michael Plass:PARC:Xerox
Subject: Re: Torches Discussion
To: Pavel Curtis:PARC:xerox
Cc: PCedarImplementors:PARC:Xerox

I think there ought to be "forwarding pointers" somewhere (e.g., under
/WORLD/torches/) to indicate the presence of shared packages.  Thus if
you asked for either the PCedar or Cedar torch for Gargoyle, you would
get the CedarCommon torch, but if you asked for the PCedar BasicPackages
torch (not shared), you would get just the PCedar torch.

Since this information changes infrequently, I would think the best
policy would be to have it contained in one file, (which would, of
course, be covered by a DF file, and hence there would be a torch for
it).  It would be the place to look to find out exactly which packages
are source shared.

I think Tim's concern about who can take torches and who can't is not
really a problem, since the set of people who can take a torch in a
particular world is precisely the set of people who can SModel to that
world (by virtue of the fact that torches are just files).
    (N.B. this presumes the ability to delete files; we may want to
    change the torch implementation so that it does not require deletes.
    This would also provide some history, by virtue of file versions.)
	 9-Mar-90	Pavel Curtis	Re: Torches Discussion
Date: 09 Mar 90 13:59:36 PST
In-reply-to: "Christian P Jacobi:PARC:Xerox's message of Thu, 01 Mar 90 11:52:19 PST"
Sender: Pavel Curtis:PARC:xerox
Subject: Re: Torches Discussion
To: Christian P Jacobi:PARC:Xerox
Cc: PCedarImplementors:PARC:Xerox

    Date: Thu, 01 Mar 90 11:52:19 PST
    In-reply-to: "Pavel Curtis:PARC:xerox's message of 01 Mar 90
    10:35:52 PST"
    Sender: Christian P Jacobi:PARC:Xerox
    Subject: Re: Torches Discussion
    To: Pavel Curtis:PARC:xerox
    Cc: PCedarImplementors:PARC:Xerox
    
    1) I think torches are a good idea and long overdue.
    
    2) I am absolutely against declaring a feature mandatory before it
    is not implemented and tested.
    
    3) Torches is a technical solution and needs a description of the
    problem it solves.  E.g. once we have torches could everybodys
    summer intern take the torch of Rope.mesa and change it? What are
    the rules?
    
    Christian
       


1) Good.

2) You have not yet answered my question as to the way in which the
torch stuff is either unimplemented or untested.  A glance at the output
of TorchTaken? tells me that (at least) Beretta, Willie-Sue, Bier,
Foote, Sturgis, Peter, Jacobi (!!), Pavel, Wyatt, Norman, and Spreitzer
are currently using the software and the fatc that I have received no
bug reports at all suggests that they are doing so productively.

3) I agree that someone needs to tell interns what they can and cannot
do without checking with someone else.  I don't thank that that is
relevant to the adoption or non-adoption of the torch service.

	Pavel
	 9-Mar-90	Pavel Curtis	Re: Torches Discussion
Date: 09 Mar 90 14:01:35 PST
In-reply-to: "Kenneth A Pier:PARC:Xerox's message of 01 Mar 90 12:30:03 PST"
Sender: Pavel Curtis:PARC:xerox
Subject: Re: Torches Discussion
To: Kenneth A Pier:PARC:Xerox
Cc: Pavel Curtis:PARC:xerox, PCedarImplementors:PARC:Xerox

    Date: 01 Mar 90 12:30:03 PST
    In-reply-to: "Pavel Curtis:PARC:xerox's message of 01 Mar 90
    10:35:52 PST"
    Sender: Kenneth A Pier:PARC:Xerox
    Subject: Re: Torches Discussion
    To: Pavel Curtis:PARC:xerox
    Cc: PCedarImplementors:PARC:Xerox
    
    Confusing (to me) discussion occured earlier about the granularity
    of
    torches.  It looks like a torch is defined by a -Suite.df existing
    for a
    package for which one can manipulate a torch.  True? Are there other
    options currently implemented?


In the current implementation, torches are defined by the existence of a
Package.df or Package-Suite.df file in the Top directory of a given
world.
	 9-Mar-90	Pavel Curtis	Re: Torches Discussion
Date: 09 Mar 90 14:11:42 PST
In-reply-to: "Christian P Jacobi:PARC:Xerox's message of Thu, 01 Mar 90 12:44:34 PST"
Sender: Pavel Curtis:PARC:xerox
Subject: Re: Torches Discussion
To: Christian P Jacobi:PARC:Xerox
Cc: Pavel Curtis:PARC:xerox, PCedarImplementors:PARC:Xerox

    Date: Thu, 01 Mar 90 12:44:34 PST
    In-reply-to: "Christian P Jacobi:PARC:Xerox's message of Thu, 01 Mar
    90 11:52:19 PST"
    Sender: Christian P Jacobi:PARC:Xerox
    Subject: Re: Torches Discussion
    To: Christian P Jacobi:PARC:Xerox
    Cc: Pavel Curtis:PARC:xerox, PCedarImplementors:PARC:Xerox
    
    About granularity:
    	I vote for using the short name.  Separating torches for DCedar and
    PCedar will cause me to frequently use the wrong torch.   Anyway
    DCedar and PCedar developpment should not digress too far, and, if
    it does those implementors might consider sharing a torch and use a
    fine grain mechanism between them.
    Christian


I think the short name must be paired with the world name.  I disagree
that DCedar and PCedar ``should not'' diverge.  For example, I see no
reason to continue support for Peanut in DCedar (other than the fixing
of major work-stopping bugs).  Thus, my work on Peanut is being done
only in PCedar.  I don't want the torch for DCedar Peanut at all.

I don't think that it's too much to ask (assuming that the torch service
is used in DCedar at all) that people trying to make the two stay in
synch remember to take both torches.  You could even define yourself a
simple little alias for it:

    Alias TakeBoth (name) TakeTorch -w PCedar name; TakeTorch -w
    CedarChest7.0 name

	Pavel
	 9-Mar-90	Mike Spreitzer	Re: Torches Discussion
Date: Fri, 09 Mar 90 14:17:59 PST
In-reply-to: "Pavel Curtis:PARC:xerox's message of 09 Mar 90 14:11:42 PST"
Sender: Mike Spreitzer:PARC:Xerox
Subject: Re: Torches Discussion
To: Pavel Curtis:PARC:xerox
Cc: Christian P Jacobi:PARC:Xerox, PCedarImplementors:PARC:Xerox

I have defined myself such aliases (SGiveTorch, STakeTorch, STorchTaken?; S for Shared).  How about making the torch package itself define such aliases, rather than force us each to invent them on our own?

Mike
	 9-Mar-90	Pavel Curtis	Re: Torches Discussion
Date: 09 Mar 90 14:16:39 PST
In-reply-to: "Tim Diebert:PARC:xerox's message of Thu, 01 Mar 90 13:00:51 PST"
Sender: Pavel Curtis:PARC:xerox
Subject: Re: Torches Discussion
To: Tim Diebert:PARC:xerox
Cc: Pavel Curtis:PARC:xerox, PCedarImplementors:PARC:Xerox

    Date: Thu, 01 Mar 90 13:00:51 PST
    In-reply-to: "Pavel Curtis:PARC:xerox's message of 01 Mar 90
    10:35:52 PST"
    Sender: Tim Diebert:PARC:xerox
    Subject: Re: Torches Discussion
    To: Pavel Curtis:PARC:xerox
    Cc: PCedarImplementors:PARC:Xerox
    
    We need to be very careful about mandating things for PCedar without
    remembering that PCedar lives in places other than Palo Alto.  In
    some
    case there is TCP/IP service to these places and others only have
    XNS. 
    Personally I think torches are a wonderful idea.  How to implement
    them
    to be useful all over the Corporation is another mater.
    
    Tim


I appreciate the importance of this issue, but I think that there's a
misconception here.  If I am a user of PCedar without TCP/IP and NFS
connection to PARC, then it is already the case that I cannot (safely)
make changes to PCedar packages without coordinating with some
intermediary who IS so connected.  The situation in which the torches
are maintained electronically rather than through the person of
Willie-Sue is no different in this respect.

I believe that the torch service is merely taking the place of talking
directly to Willie-Sue; this relieves her of a burden and also makes it
possible to do coordination even when she is unavailable.  I am not
trying to solve all of the world's interlocking problems with Give and
Take, just this one simple case.

	Pavel
	 9-Mar-90	Pavel Curtis	Re: Torches Discussion
Date: 09 Mar 90 14:42:10 PST
In-reply-to: "Michael Plass:PARC:Xerox's message of 01 Mar 90 17:19:11 PST"
Sender: Pavel Curtis:PARC:xerox
Subject: Re: Torches Discussion
To: Michael Plass:PARC:Xerox
Cc: Pavel Curtis:PARC:xerox, PCedarImplementors:PARC:Xerox

    Date: 01 Mar 90 17:19:11 PST
    Sender: Michael Plass:PARC:Xerox
    Subject: Re: Torches Discussion
    To: Pavel Curtis:PARC:xerox
    Cc: PCedarImplementors:PARC:Xerox
    
    I think there ought to be "forwarding pointers" somewhere (e.g.,
    under
    /WORLD/torches/) to indicate the presence of shared packages.  Thus
    if
    you asked for either the PCedar or Cedar torch for Gargoyle, you
    would
    get the CedarCommon torch, but if you asked for the PCedar
    BasicPackages
    torch (not shared), you would get just the PCedar torch.
    
    Since this information changes infrequently, I would think the best
    policy would be to have it contained in one file, (which would, of
    course, be covered by a DF file, and hence there would be a torch
    for
    it).  It would be the place to look to find out exactly which
    packages
    are source shared.
    
    I think Tim's concern about who can take torches and who can't is
    not
    really a problem, since the set of people who can take a torch in a
    particular world is precisely the set of people who can SModel to
    that
    world (by virtue of the fact that torches are just files).
        (N.B. this presumes the ability to delete files; we may want to
        change the torch implementation so that it does not require
    deletes.
        This would also provide some history, by virtue of file
    versions.)


I would be willing to implement such forwarding pointers.  I would
implement them differently, though, by simply putting the forwarding
information in the torch itself.  Suppose that we had a new command with
this syntax:

    ShareTorches <shared-world> <package-name> {<unshared-world>}+

Thus, to set up a CedarCommon torch for the PCedar and CedarChest7.0
versions of Gargoyle, you would say something like

    ShareTorches CedarCommon Gargoyle PCedar CedarChest7.0

This would attempt to grab the Gargoyle torches in both PCedar and
CedarChest7.0 and, if succesful, would write the forwarding information
in the files for those two torches, saying that grabbing them requires
grabbing the CedarCommon torch for Gargoyle instead.  One could imagine
an UnShareTorches command as well that undoes this mess:

    UnShareTorches [-w <any-one-unshared-world _ "PCedar">] 
    {<package-name>}+

It only needs one of the names for the unshared worlds because I can
store all of the names in each of the forwarding pointers.  This command
would attempt to grab the (still shared) torch for the named package
and, if successful, would remove all the forwarding pointers and then
release the shared (and now obsolete) torch.

On Michael's final point, that we use file versions to represent
history, it's an interesting idea.  Does anyone have an idea for how to
implement it?

	Pavel
	 9-Mar-90	Michael Plass	Re: Torches Discussion
Date: 09 Mar 90 22:45:20 PST
In-reply-to: "Pavel Curtis:PARC:xerox's message of 09 Mar 90 14:42:10 PST"
Sender: Michael Plass:PARC:Xerox
Subject: Re: Torches Discussion
To: Pavel Curtis:PARC:xerox
Cc: Michael Plass:PARC:Xerox, PCedarImplementors:PARC:Xerox

re: Does anyone have an idea for how to implement [use of file versions to represent history]?

Let there be a distingushed username, 'nobody'.  If you only pay attention to foo.torch!h, and you say it is OK to take a torch iff 'nobody' owns it or it does not exist, and you implement GiveTorch by letting 'nobody' steal it, you get the history for free on a versioned file system.  The torches still work OK on an unversioned system (except for a race condition), but you get no history.

I think Pavel's proposed implementation of shared torches is fine.

����
"Mail" style�J�
receivedHeader�*Idefault����4L���

sentHeader�2L����0L����4L����-L����/L��	��.L����.L����.L����0L����.L��
��.L����/L������=�>�