Re: [Anima] GRASP API in C?

[Michael Richardson]

Brian E Carpenter  wrote:
>> Brian E Carpenter  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.

> 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.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Re: [Anima] GRASP API in C?

[Brian E Carpenter]

On 25/03/2017 11:46, Michael Richardson wrote:
> 
> Brian E Carpenter  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.

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...).

> > 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.
> 
> 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.

  Brian

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima