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