Re: two issues of terminology

>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
>
>
>_______________________________________________
>services-wg mailing list
>services-wg@...
>http://lists.geni.net/mailman/listinfo/services-wg