Re: Updated dataflow semantics for RTT

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-160333113-1443452811=:32467
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On Mon, 28 Sep 2015, Stephen Roderick wrote:

>
> On Sep 28, 2015, at 08:42 AM, Sylvain Joyeux <[email protected]> w=
rote:
>
> Some thoughts on that executive summary (I'm like geoffrey, I had a
> hard time following the first email :P)
> =C2=A0
> +1
>
> One thing I definitely want to warn you about: don't think, ever, that
> code-generating everything is a replacement for a well-designed
> library that solve most of the problems, along with a code generator
> for the one percent.
> =C2=A0
> +1
>
> Also, code generators introduce an additional level of indirection and=20
> dependency. In some cases, it isn't worth that burden.
>
> With this premise: I actually that your points are not making RTT
> obsolete. It is actually making it even more relevant than ever.
>
> RTT *is* the best starting point towards something where
> process/thread policies is delegated to the tooling (either accessing
> "raw" OS-specific functionality or exposing them under an
> easier-to-use interface). It is also *already* provides an
> encapsulation of computation, which allows you to "inverse" the
> current tendency and actually make your middleware central to your
> communication setup -- instead of hiding it behind a common API.
> =C2=A0
> +1
>
> Also, RTT is cross-platform. Linux isn't the be all and end all for eve=
ryone=20
> =E2=80=A6 so for us, systemd (or any other Linux-specific dependency) c=
an't be a=20
> central part of any proposed replacement.

You're fooling yourself: RTT is a dependency which is a lot more risky th=
an
dependencies that are widely supported and maintained in mainstream IT
developments... :-)

> S

Herman
--8323329-160333113-1443452811=:32467
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev

--8323329-160333113-1443452811=:32467--