[services-wg] two issues of terminology

[Jeff Chase]

It seems we all agree that there is a useful distinction between 
"programming tools" and "experimenter tools" for a slice.  And we're 
still trying to pin down the exact nature of the distinction.

IMHO, we shouldn't work too hard to make the definition precise, because 
there is no bright line.  There may be tools that cross whatever line we 
draw.   This definition seems pretty good:

Robert P Ricci wrote:
> ...
> An experimenter tool *sets up* the environment in which a system under
> test runs, a programming tool is (may be?) *part* of that environment.
>
> More specific, but maybe not quite right:
>
> A programming tool is one that is in the "codepath" (broadly defined) of
> the system under test - that is, it's directly involved in the
> experiment because my application calls it as a library, makes syscalls
> into it, sends packets through it, etc. An experimenter tool is outside
> this codepath in that the interaction is one way - the experimenter tool
> might "call into" the SUT to start it, modify its configuration, etc,
> but the SUT doesn't "call into" the experimenter tool. (And in the case
> of collaboration tools and similar things, the tool may never really
> interact with the SUT at all.)
>
>   
But that almost suggests that the System Under Test cannot notify the 
experimenter tools (e.g., slice controller) about events within the 
SUT.  We can dodge that by saying that the SUT exposes/publishes events 
and the external controller subscribes to those events, so that the SUT 
does not have to invoke the controller or know about it.   But that just 
encapsulates the line in a publish/subscribe system somewhere.   (Not 
that there's anything wrong with that.)

To me it seems most straightforward to think in terms of where code 
runs, something like so:

- A "programming tool" consists of or produces 
(creates/generates/combines/links) code to run within some sliver.   
Different component/sliver technologies might come with their own 
programming tools or libraries of off-the-shelf programs or modules 
specific to those kinds of slivers.   That's one reason why the 
distinction seems useful: so we can talk about programming tools for 
specific kinds of components or slivers.  (Of course, the programming 
tool itself could run anywhere.)

- An "experiment tool" is a tool that manages a slice on the 
experimenter's behalf, but does not run within a sliver or produce code 
that runs within a sliver.   That sort of makes sense...certainly a 
slice can't pull itself up by its own bootstraps, i.e., the code that 
initially sets up a slice can't run within any of the slice's slivers.   
Experiment tools should strive to be general across many 
component/sliver technologies, although they will have to "talk about" 
various component/sliver technologies, i.e., they might have to produce 
and consume various metadata or representations.

I emphasize again that it's not a bright line.  I could imagine an 
experiment tool that does some management or control that is specific to 
a particular kind of sliver and/or comes with an agent that runs within 
specific sliver types.  And we all want long-running slices to be 
self-monitoring and self-managing, so there could be families of tools 
for programming some kind of reflection into slices---what are they?  
One reason to draw the line is to make it more interesting to cross it.

Jeff