Integrate feedback on Discovery and Negotiation article

[wjwwood]

Based on feedback, changes todo:

• Use the term communication graph rather than data layer graph or data layer.
• Write abstract
• Rewrite problem space as a more structured Introduction
• Refactor the "open issues" to be deferred topics, as they will be discussed else where
• Make use cases more concrete, put in terms w.r.t. ROS 1.x
• Make a concrete proposal for how we should act on this information, include:
  • what design decisions to make
  • what the vision for the new system should be
  • implementation details
• Add conclusion/summary

From @dirk-thomas:

terms:
computational graph vs. communication graph
(instead of data layer graph since it is too similar to data layer in networks)

--

toc

introduction
  concept to get from computational graph to data layer graph
  proposal of abstract interface to enable different strategies with different use cases in mind

summary
  several use cases with increasing complexity how to discover / negotiate
  proposed interfaces to enable these flexible scenarios

deferred topics (instead of open questions, because we don't them to be answered for this wp):
* graph communication: used protocol, serialization, transport
* configuration / hints for serialization, transport etc.
* remapping

next steps:
* work on API details, implement prototype as proof-of-concept
* specification of interfaces and wire protocol

From @gerkey:

Suggestions regarding content:

* Wherever possible, be more concrete.  I found the use cases section
abstract to the point of being difficult to read, and I consider
myself somebody who's both knowledgeable about and interested in this
stuff.  It might help to make more references to ROS 1.0.  It's a
well-known system that will be familiar to most readers, and many
people will grasp the content more quickly if it's phrased as a set of
changes/improvements to an existing system.

* In the proposal section in particular, be more concrete. I got a lot
of background, but I didn't come away with an understanding of how you
intend to implement Discovery or Negotiation.  Will we use one master?
 Will we use multiple masters?  Will we use zerconf?  Will we try to
support everything?

* Building on the previous point, my overall perspective on this and
the other papers:

---
With years of experience using and developing ROS, plus significant
time spent recently considering what we would like to change, we are
in a position to recommend, on every important question, one or more
very specific paths forward.  We should not shy away from making
choices and tradeoffs; rather we should, based on our knowledge and
experience, boldly prescribe specific changes that we believe are the
best next steps.

I want the reader to come away with an understanding of exactly what
we intend to do and why, perhaps with a handful of open questions
where we haven't yet decided between option A and option B.

E.g., after reading the Discovery & Negotiation paper, the reader
should think something of the form:

"OK, the ROS guys are going to make ROS 2.0 a multi-master system in
which the masters find each other via zerconf.  That's not exactly the
way that I would do it, but understand their reasoning and I believe
that it'll work well.  They haven't yet decided whether an individual
node is allowed to associate with multiple masters; I'm going to weigh
in and suggest that they don't allow, or at least recommend against,
that capability, because I think that it'll make client libraries
overly complex."

---

Suggestions regarding organization, which we discussed on Friday:

* Add an Introduction (or Abstract) that summarizes what the paper
will say, including the conclusions (e.g., important findings and
proposed changes).  I want to start out knowing where you're headed,
what argument you're making, and what you're going to recommend at the
end.
* Add a Conclusion/Summary at the end that wraps things up; the last
thing I read should be a concise statement of what you've decided to
do.

These comments should be integrated into the document as changes.