Subject: [Anima] GRASP API in C?

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Mar 2017 11:41:57 +1300

Hi,

We will discuss the GRASP API (https://tools.ietf.org/html/draft-liu-anima-grasp-api-03) in Chicago.

One related topic is how to map this API into C, which is perhaps the most fundamental mapping.

People with more C coding experience than me: please look at the attached header file. All kinds of comments are needed.
 
Regards
   Brian Carpenter

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Mar 2017 11:43:43 -0400

> We will discuss the GRASP API
    > (https://tools.ietf.org/html/draft-liu-anima-grasp-api-03) in Chicago.

    > most fundamental mapping.

As someone who writes lots of C, I am not convinced this is a useful exercise.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Mar 2017 07:12:23 +1300

> As someone who writes lots of C, I am not convinced this is a useful exercise.

Can you explain? If you're arguing that no ASAs will be written in C, that's
defensible, but maybe that isn't your argument?

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Mar 2017 14:46:44 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> Brian E Carpenter <[email-masked]> wrote: > Hi,
    >>
    >> > We will discuss the GRASP API >
    >> > One related topic is how to map this API into C, which is perhaps
    >> the > most fundamental mapping.
    >>

    > Can you explain? If you're arguing that no ASAs will be written in C,
    > that's defensible, but maybe that isn't your argument?

I think that ASAs that are written in C will be written in that language for
reasons of extreme constraints. As such, they won't bother with a
library/API.  It will all be statically initialized globals and other stuff.
(Go read the Contiki code for an example of what I mean...)

Everyone else will write their ASAs in a higher level language: python, ruby,
perl, java, scala, *go*, maybe rust.   The really hard thing about the C api
is that doesn't deal well with indefinites like intents...

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Mar 2017 09:02:33 +1300

> is that doesn't deal well with indefinites like intents...

It doesn't deal well with flexible types either, a dangerous luxury in Python
that I've got very fond of. But it seems to me that if a GRASP core implementation
is written in C for efficiency, it will *need* to offer an API in C that higher
level languages can build on.

And if we are happy with a core written in a high level language, we'll
need to call it from other languages. That can be complicated too.

BTW, my not-production-quality Python version of the GRASP core is now 
about 1800 lines of code, but if we take out the stuff for diagnostics and
debugging there's maybe 1000 lines. I hope we'll find out in the hackathon
how big the BUPT code is; so far they don't support an API, so they are
on your model.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Mar 2017 18:46:40 -0400

Brian E Carpenter <[email-masked]> wrote:
    > It doesn't deal well with flexible types either, a dangerous luxury in
    > Python that I've got very fond of. But it seems to me that if a GRASP
    > core implementation is written in C for efficiency, it will *need* to
    > offer an API in C that higher level languages can build on.

No, because it will be monolithic: not part of a library, no sockets API, etc.

    > about 1800 lines of code, but if we take out the stuff for diagnostics
    > and debugging there's maybe 1000 lines. I hope we'll find out in the
    > hackathon how big the BUPT code is; so far they don't support an API,
    > so they are on your model.

My understanding is that uPython is getting significant traction in some
constrained environments: someone may want to rewrite your code to this
very limited subset (less than python 2, I'm told).  I think that this is
more likely to be a "library" than any C code.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 Mar 2017 02:25:59 +1300

> No, because it will be monolithic: not part of a library, no sockets API, etc.

It can't be monolithic in a general-purpose device with a variety of ASAs
sharing a discovery cache, flood cache, etc. Well, I'll show you my code
later today if you like. (I will get to the hackathon at a time that depends
on service on the Red Line train...).

> more likely to be a "library" than any C code.

I know nothing about uPython. I did look at downgrading my code to Python 2
but quickly gave up because, well, Python 3 is better. So it all depends
on what they've kept and what they've removed in uPython.

  Brian

---

From: Michael Richardson <[email-masked]>
Date: Sat, 25 Mar 2017 12:21:53 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> Brian E Carpenter <[email-masked]> wrote: > It doesn't
    >> deal well with flexible types either, a dangerous luxury in > Python
    >> that I've got very fond of. But it seems to me that if a GRASP > core
    >> implementation is written in C for efficiency, it will *need* to >

    > It can't be monolithic in a general-purpose device with a variety of
    > ASAs sharing a discovery cache, flood cache, etc. Well, I'll show you

Exactly: it can't be monolithic on a general-purpose device.
When it's not a general-purpose device, that's when writing it in C will be
required.

    >> My understanding is that uPython is getting significant traction in
    >> some constrained environments: someone may want to rewrite your code
    >> to this very limited subset (less than python 2, I'm told).  I think
    >> that this is more likely to be a "library" than any C code.

    > I know nothing about uPython. I did look at downgrading my code to
    > Python 2 but quickly gave up because, well, Python 3 is better. So it
    > all depends on what they've kept and what they've removed in uPython.

I don't know much about it either.