Agreed.
Incremental, evolutionary changes rolled out on a shorter time frame seems
a much safer development course. If there is a reason to couple API
changes to the build system to the network protocol, I haven't seen it.
After seeing comments from Micheal Harbler and Valerio De Carolis, I am
still quite concerned about the choice of DDS. At issue is
responsiveness, vitality, community. A perusal of the DDS code repositories
show that the are almost stagnant, with OSRF already being the single
largest contributor to them. This belies the idea of leaving "networking to
the experts": if OSRF becomes the principle user and lead maintainer for
DDS, then its not leveraging a community of knowledgeable experts. It could
be a manpower sink, rather than a benefit.
The dig w.r.t corba is real: perhaps it took a few decades for corba to
become usable; the fact remains its not much used (I feel responsible for
the one exception: having goaded the gimp/gtk/gnome foundation into using
it 15-20 years ago, for which I am sincerely sorry. ).
Its important to understand why this is the case: its because OMG does not
use a community process or an RFC-style process. This is why its products
are moribund. Compare this to the vitality seen in the IETF, or, closer to
home, the zeromq RFC process. The community process has worked well over
these decades; abandoning it for a core technology component seems
foolhardy.
-- Linas
On Tue, Sep 29, 2015 at 5:38 PM, Bill Morris via ros-users <
ros-users@lists.ros.org> wrote:
> Why are these goals (transport/build system) dependent on each other?
> Doing ROS1.5 as an interim release seems like lower risk and less work.
>
> On 09/29/2015 05:17 PM, Mike Purvis via ros-users wrote:
> >> Note here that all the goals that OSRF presents are perfectly achievable
> >> using a different strategy: ROS1.5. ROS1.5 means building nodes that
> talk
> >> via the ROS1 protocol, but are built using ROS2 infrastructure and
> >> libraries.
> >
> > Another view of "ROS1.5" would be where APIs (especially the C++ API) are
> > maintained even as the underlying transport and serialization is changed
> > around, an improved node/nodelet/launch scheme is developed, etc.
> >
> > I support the DDS direction, but it does seem to be an all-or-nothing
> > affair, and that's one of the biggest bummers about it.
> >
> > M.
> >
> >
> >
> > _______________________________________________
> > ros-users mailing list
> > ros-users@lists.ros.org
> > http://lists.ros.org/mailman/listinfo/ros-users
>
> _______________________________________________
> ros-users mailing list
> ros-users@lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users
>
_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
(text/plain)