RE: Current Practices Freeze

Hi Ari,

Perhaps it's the implementation I'm using (node-coap) or something about my environment, but I've never managed to get very quick responses to messages (at least not quick enough for it to feel instant to a user). If you'd care to share your project or the stack you're using I'd be really interested to see what you're doing. I'm aware there's quite a wide distribution for this list, so specifics might be better discussed privately.

Thanks,
Alex
________________________________________
From: Ari Keränen [ari.keranen@ericsson.com]
Sent: 16 June 2016 18:44
To: Owen A.R.
Cc: Kovatsch, Matthias; public-wot-ig@w3.org
Subject: Re: Current Practices Freeze

Hi Owen,

I was wondering why isn't CoAP real-time enough for your applications?

My experience is that there's no problem using CoAP in applications that require sub 5ms delay (including both network transfer and processing). Actually CoAP works better than most alternatives due to the small protocol overhead and easy processing, even in non-constrained use cases.


Cheers,
Ari

> On 16 Jun 2016, at 11:57, Owen A.R. <Alex.Owen@soton.ac.uk> wrote:
>
> Hello Matthias,
>
> I am very much in favour of a WebSockets binding, HTTP/COAP is nowhere near real time enough for the kind of applications I'm doing (UI grade, sub 200ms across multiple devices).
>
> If I can find the time to add to the document I will, but I don't think I can for a couple of weeks at least. I did want to show my support though.
>
> BLE and MQTT I could take or leave though. BLE is always going to need to connect to a hub, and by the time you're on the hub you're probably going to need something more lightweight than the TD for embedded devices. And MQTT is far too inflexible to hold up long term (IMO).
>
> Thanks,
> Alex
> ________________________________
> From: Kovatsch, Matthias [matthias.kovatsch@siemens.com]
> Sent: 14 June 2016 22:52
> To: public-wot-ig@w3.org
> Subject: Current Practices Freeze
>
> Dear group
>
> We intended to freeze the Current Practices document end of last week. Unfortunately, this was not possible because we are lacking contributions to the document.
>
> On the positive side, Taki provided a pull-request that added the new type system prototype based on JSON Schema to the document (http://w3c.github.io/wot/current-practices/wot-practices.html#type-system). Sebastian introduced the updated to the TD (http://w3c.github.io/wot/current-practices/wot-practices.html#sec-td) and I added documentation of our current Protocol Bindings (w3c.github.io/wot/current-practices/wot-practices.html#protocol-bindings), made several corrections, and tried to improve the overall structure.
>
> What we are still missing is the following:
>
> -        Johannes needs help to update the Scripting API section
>
> -        The Discovery section is still the strawman I put in when creating the document
>
> -        Has anyone other than Michael looked into the MQTT Binding? MQTT, BLE, and WebSockets do not have any bindings yet. Still, there is the assumption that people would like to have these protocols… do they? (meaning, we would need some proposals for the Bindings)
>
> -        Security howto for implementers: Oliver currently cannot help. Can anyone who implemented this for the Nice PlugFest provide a write-up of how to use security? If (D)TLS was used, this would need to go into a new section 3.1.3. The JWT usage must go into 3.2.6.3
>
> -        There is now text on how to extend the TD with semantic models (3.2.6.1). Here our example context should also be explained…
> Any volunteers?
>
> Furthermore, you are welcome to review http://w3c.github.io/wot/current-practices/wot-practices.html and provide me with feedback. I want to have at least a stable version of the technical aspects by Friday, since I will present this in the Eclipse IoT Webinar. Editorial changes can still follow after that, but I want to already have the document available at its “Release URI” (w3c.github.io/wot/current-practices/wot-practices-beijing-2016.html).
>
> Best regards
> Matthias
>

Received on Thursday, 16 June 2016 18:17:10 UTC