<scribe> scribe: zkis
<kaz> Sep-28
Minutes approved
Cristiano: what is the use case
here
... the emitEvent() fails or reporting to the client side
Zoltan: both
Daniel: on the ExposedThing side if emitEvent() fails
Cristiano: what about the other use case
Zoltan: this is in the context of the
native protocol stacks and pairs the subscribe side error
callback with the server side event error reporting
... I will place a similar comment on the client side, to make
it more clear.
Cristiano: agree
Zoltan: will improve the PR and leave the PR still open for comments.
Daniel: could we close this
Zoltan: yes, the feedback was addressed
Daniel: it could be reopened on need
Zoltan: this will be fixed by the outstanding PR when it's ready and merged
Zoltan: pretty old formulation, should be updated with current Thing Directory developments
Daniel: we used to have this feature, but not any longer
Zoltan: we don't now have a WoT-specific algorithm to report a TD update, it can be done by an Event inside a TD
Cristiano: that's a problem
Zoltan: we can remove this
section
... and we need to check the whole Security section
Daniel: volunteering for that
<scribe> ACTION: DP to check the Security section and fix #252
Zoltan: explaining the issue history and comments
Cristiano: we can go with the current
API, errors reported by 2 different mechanisms, but...
... but we could pass the callbacks right after calling
subscribeEvent()
Zoltan: exactly
Daniel: I prefer the current API instead of a Subscription object where we call start() etc
Zoltan: we also have a semantic mix between WoT Event listener and DOM EventListener, maybe better to avoid that with callbacks
Cristiano: we are missing the "once"
specifier from subscriptions
... as a convenience
Daniel: it's a bit more complex
Zoltan: so we are lifting "once" from
EventTarget
... we used to have a spec version that used a part of
EventTarget (supporting "once" but not the other options).
Cristiano: so we acknowledged the issue and might want to use events after all
Zoltan: quite difficult to specify it
that way, but we should think
... what about publishing the current API and figure it out in
the next version?
Daniel: fine with that, and we should add convenience "once" eventually
Cristiano: need to try that
<kaz> [adjourned]