Hello,
Thank you for the responses so far.
On Wed, Nov 30, 2016 at 6:49 AM, Dwarkaprasad Dayama <
dwarka.dayama at samsung.com> wrote:
> This requirement has been handled in form of observable /oic/res and it is
> part of OCF 1.0.
>
> /oic/ad was removed from Spec because it was underspecified and there was
> better way to do same using /oic/res and avoiding new resource creation.
>
Thank you, that clarifies. Observing /oic/res will give client apps
notifications when resources appear and disappear.
Also, the CoAP way Mats mentioned solves this case: if the observing client
stack gets a retrieve response with a 4.04 error, the client app will know
it has to re-discover. However, I like more the solution with observing
/oic/res, since clients don't need to rediscover.
I also fully agree with Thiago Macieira that a resource directory should be
mandatory in an OCF network.
However, none of these solve the problem when the device is gone and there
is no one to run /oic/res (or resource directory). For solving that on
protocol level, we'd need a network entity that monitors devices in a
network and provides notifications to observers when devices disappear and
re-appear. That would make this entity (and resource directory) mandatory
in the network, with backups, sync and failover mechanisms needed.
Alternatively, device implementations could keep /oic/res observers in a
persistent state that survives device reboots, so that the device could
resume sending /oic/res related notifications after rebooting. The goal is
that clients don't need to re-discover. This is an implementation detail,
but the Spec should formulate a wording for the recommended way to handle
the use case.
We really want to avoid client apps solving this problem by polling.
Also, we want to keep servers efficient: any observe subscription should
expire after a timeout, or when the server max capacity is reached. There
should be an error code with retrieve responses for that ("this was the
last update, please renew subscription"). This would help keeping servers
clean from disappearing clients.
Best regards,
Zoltan
>
> *From:* coretech_wg at openconnectivity.org [mailto:coretech_wg@
> openconnectivity.org] *On Behalf Of *Mitch Kettrick
> *Sent:* Wednesday, November 30, 2016 1:37 AM
> *To:* 'Kis, Zoltan'; coretech_wg at openconnectivity.org; architecture_tg@
> openconnectivity.org
> *Subject:* RE: [coretech_wg] Fwd: presence?
>
>
>
> Hi Zoltan,
>
>
>
> Several Resources were removed from the core spec because a) they weren?t
> included in IoTivity and b) we didn?t have any test cases written to
> validate them.
>
>
>
> If this feature and the ?rt? oic.wk.ad are in fact supported in IoTivity
> then we need to add them back into the core spec and write test cases that
> will validate proper behavior.
>
>
>
> Would you be able to write a submission/CR to add this functionality back
> to the core spec to align with what is implemented in IoTivity? I can work
> with you to develop corresponding test coverage to validate it.
>
>
>
> Thanks,
>
> Mitch
>
>
>
> *From:* coretech_wg at openconnectivity.org [mailto:coretech_wg@
> openconnectivity.org <coretech_wg at openconnectivity.org>] *On Behalf Of
> *Kis,
> Zoltan
> *Sent:* Tuesday, November 29, 2016 3:46 AM
> *To:* coretech_wg at openconnectivity.org
> *Subject:* [coretech_wg] Fwd: presence?
>
>
>
> Hello,
>
> It seems the OCF Core spec 1.1 does not deal with presence any more: the "
> oic.wk.ad" resource type and the "/oic/ad" resource are not specified any
> more - or then it's just me who doesn't find them.
>
> iotivity still seems to support "enablePresence()" and "disablePresence()"
> that are based on the "/oic/ad" resource. That sounds obsolete now.
>
>
>
> I wonder what are the current mechanisms in OCF that support the following
> use cases:
>
> - when a server deletes/unregisters a resource, observers of that resource
> SHOULD get delete notifications
>
> - [sub-case] when a client deletes a remote resource, observers of that
> resource SHOULD get delete notifications
>
> - when a server device goes down, observers for that should get
> notification instead of trying to fetch resources of that device in vain.
>
> Without these, client applications need to do periodic discovery and
> maintain their own lists of resources and devices. This is catastrophic for
> network and battery efficiency when we scale it up to the projected number
> of IoT devices.
>
> A resource/device directory should be able to encapsulate this - is a
> resource directory guaranteed to be in the OCF network nowadays?
>
> I wonder what are the recommended client work flows the current OCF Core
> spec is supporting. Right now it seems that a client first needs to look
> for a resource directory; if there is one, use it. Otherwise set up
> periodic discovery and maintain own resource/device list.
>
>
>
> Thanks,
>
> Zoltan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20161130/e6575352/attachment.html>
