[ell-i-developers] Re: Initial spec for a CoAP API
- From: Pekka Nikander <pekka.nikander@xxxxxx>
- To: ell-i-developers@xxxxxxxxxxxxx
- Date: Thu, 27 Feb 2014 14:10:49 +0200
I pushed now the work-in-progress into a separate feature-coap-wip branch:
https://github.com/Ell-i/Runtime/commit/76f19afae72ef96ec5710f31a2eaebf7dd53aca5
It is still far from working, but now the skeleton is missing just a couple of
bones any more.
--Pekka
On 2014–02–25, at 22:26 , Pekka Nikander <pekka.nikander@xxxxxx> wrote:
> I have now a preliminary skeleton for the CoAP API and some initial code for
> the implementation; far from ready though.
>
> For the API, the idea is to define CoAP URLs at compile time, storing all the
> data structures in the flash, in a manner similar to how we handle peripheral
> initialisation now.
>
> As an example of a temperature sensor, the API might look like the following:
>
> static void temp_sensor_get(char *buffer, const char *format) {
> iprintf(buffer, format, ...);
> }
>
> DEFINE_COAP_GET_URL("/sensors/temp", temp_sensor_get,
> { COAP_FORMAT_TEXT_PLAIN, "%d" },
> { COAP_FORMAT_APPLICATION_JSON, "{ \"temperature\": \"%d\" }");
>
> The idea is that this compiles into a statically allocated data structure
> that the linker makes available to the CoAP protocol part that handles GET
> urls.
>
> The GET handler will go through all of the GET URL data structures (linearly
> at this phase), until it finds a match with the requested URL. When a match
> is found, it calls a callback function (temp_sensor_get in this case),
> passing it a pointer to a buffer where the result should be formatted (a
> pointer to the right place in the packet), and a pointer to a template for
> formatting the result. The implementation may support multiple content
> formats, as can be seen. The first one is the default one if the client does
> not specify what format it would like or if the requested format is not
> available.
>
> The callback function must not block. In the first implementation it will
> run in the interrupt context; we will move the processing to the threading
> context only once we'll have thread support in the new runtime. Even once
> moved to a threading context, it SHALL produce the result within CoAP
> ACK_TIMEOUT, which is currently 2 seconds.
>
> I don't like much the idea that we must include iprintf() for this to work,
> but so far I haven't figured out any better idea on how to format the
> results, either. Of course, the API does not necessitate the use of
> iprintf(), but without it e.g. generating JSON or XML replies is somewhat
> complicated and may produce so large code that using iprintf() is well
> justified. But YMMV; opinions sought.
>
> The PUT API is likely to be very similar, but I haven't yet been able to
> figure out what is the best way to parse the content. sscanf() is too bulky
> and insecure. I think I will leave that to the handler so that it can parse
> in an ad-hoc manner, most probably only supporting plain text messages in an
> application-specific format. Good ideas here would be very welcome.
>
> I'm not planning to support POST or DELETE methods.
>
> Comments? Suggestions for improvements?
>
> If you need more background, please have a look at these:
>
> https://ietf.org/doc/rfc6690/?include_text=1
> https://ietf.org/doc/draft-ietf-core-coap/?include_text=1
> https://ietf.org/doc/draft-bormann-core-roadmap/?include_text=1
>
> --Pekka
>
> On 2014–02–25, at 19:22 , Pekka Nikander <pekka.nikander@xxxxxx> wrote:
>
>> I have now a skeleton written for UDP and IP; I'm writing a skeleton for
>> CoAP.
>>
>> This very first version will *NOT* be compatible with the Arduino Ethernet
>> library, but will be more minimal, with all sockets and CoAP URLs
>> compile-time allocated. In this way it consumes less RAM and flash. And is
>> easier to write.
>>
>> I expect to have a first working but untested version ready on Thursday;
>> perhaps already tomorrow.
>>
>> ARP, ICMP and DHCP are still completely missing, but we can test the stack
>> without them.
>>
>> --Pekka
>>
>
>
Other related posts:
