Up until now we have a CoAP Client and a CoAP Server in all components: Registries have a CoAP Client and a CoAP Server, VAP Clients have a CoAP Client and a CoAP Server and even skills are affected by this.
This means that for every skill, we have a CoAP Server, let's say we have 1000 skills, well, then we have 1000 servers, and the problem for this is twofold:
RAM usage: Having 1000 servers around is going to use a certain quantity of RAM, even though this might be mitigated by CoAP lighweightness.
IP addresses and ports: Having so many servers means that every single server has to have their own port, this means that someone needs to keep track of which port are used.
As an alternative, CoAP has something they call Observe, which is pretty much MQTT's subscribe (whenever something is changed in the server, the client gets a notification), this way each Skill could be just be a client that "Observes" some specific URL: "coap://skill-registry/skills/my-nice-weather-skill" and when the time comes the Registry should just update that path and that Skill will get a message with the request the server has for them. Now that the Skill knows what it has to do, it can issue a "Notification" (which up until now was a mechanism for skills that wanted to send something without having any request) with a request ID, this way the registry can link the request and the answer. Skills are still able to send messages without any request (useful for things like a timer) by not sending a request ID.
CoAP observe also has a lifetime, having to renew it if the client is still interested, this can be used as a keep alive (a way of knowing that the connection is still valid).
Up until now we have a CoAP Client and a CoAP Server in all components: Registries have a CoAP Client and a CoAP Server, VAP Clients have a CoAP Client and a CoAP Server and even skills are affected by this.
This means that for every skill, we have a CoAP Server, let's say we have 1000 skills, well, then we have 1000 servers, and the problem for this is twofold:
As an alternative, CoAP has something they call Observe, which is pretty much MQTT's subscribe (whenever something is changed in the server, the client gets a notification), this way each Skill could be just be a client that "Observes" some specific URL: "coap://skill-registry/skills/my-nice-weather-skill" and when the time comes the Registry should just update that path and that Skill will get a message with the request the server has for them. Now that the Skill knows what it has to do, it can issue a "Notification" (which up until now was a mechanism for skills that wanted to send something without having any request) with a request ID, this way the registry can link the request and the answer. Skills are still able to send messages without any request (useful for things like a timer) by not sending a request ID.
CoAP observe also has a lifetime, having to renew it if the client is still interested, this can be used as a keep alive (a way of knowing that the connection is still valid).