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:
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:
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.