Meeting minutes
Past Minutes
<kaz> Jan-22
Minutes approved.
PRs
PR 561 Extended return type of invokeAction()
<cris> w3c/
Cristiano: the current starting point is to include the extensions to a single object.
Cristiano: Zoltan argued for extending the InteractionOutput object (summarizing the comment).
Cristiano: agree with the message, but we lack information due to TD 2.0 gaps
… not clear what assumptions can we make
… the proposal is to keep the feature low in the abstraction layer, i.e. add it to the ConsumedThing interface
Daniel: the solution is vague because it's underspecified
… we should acknowledge this
… so it's in the application domain how to deal with this
Cristiano: The discussion is relevant also for other op's
… in theory we support all operations
Zoltan: it's a syntactic thing where we expose canceling actions
… if canceling is not supported, it can return an error (if it's known it cannot cancel); otherwise it's a problem
Cristiano: we already have a use case for controling actions
Kaz: agree with Zoltan, think for several possible patterns for the actions and return types using several use cases.
… regarding publication of the Scripting API Note, we can publish that is in sync with the TD spec, and describe additional considerations as Editor's Notes.
<Zakim> dape, you wanted to future
Daniel: let's assume TD 2.0 will break compatibility
… Scripting might also have breaking changes
Daniel: we should do our best for current TD spec, then might do changes
Zoltan: the current design will not break, it's just extension
Cristiano: ok, but it's not a problem if we break since TD 2.0 is assumed to break things
Cristiano: the web usually is backward compatible
Jan: we can proceed with the object approach
Cristiano: the TD use cases are supported also by extending ConsumedThing, but we'd need to identify the actions (payloads), or URI variables
… both designs have ways to pass information in the headers
<kaz> PR 561 - diff for index.d.ts
Daniel: are you saying we should add options to cancel()?
Cristiano: yes
Cristiano: we can do what we do with e.g. write: options or URI variables
Daniel: what is the cancel endpoint is different?
Cristiano: that is likely a form index
Cristiano: similar to canceling subscriptions
Zoltan: so when there is no args to cancel, impls try to figure out, otherwise they take args from the app
Zoltan: ok, this doesn't change the API shape, only parameters
Cristiano: what is later this is deprecated?
Zoltan: then we add prose to say we'll ignore arguments from now on
Jan: we need implementation experience, will provide
Daniel: the status() call returns what?
Cristiano: a streaming object, since we don't know yet its format
… to be decided
Daniel: and cancel() is like stopping a subscription?
Cristiano: yes
Daniel: so these signatures are compatible
Cristiano: we can return InteractionOutput, for future flexibility
Zoltan: cancel cannot be guaranteed, but it can register user intent for canceling
Daniel: we should expose all errors we get
Zoltan: yes
Kaz: there are bigger issues than just return type
… we should decide what to include in the Note itself, and then clarify what to be done for the future Note inline with TD 2.0.
Kaz: we need use cases on how to map the returned streaming object for the 2nd point above.
Cristiano: we cannot make assumptions yet on action lifecycle data
… nor about payloads in query and cancel actions
… we can only invoke the ops of cancel and query
Zoltan: I am not sure we want an error property
Daniel: yes, and also replace status() with query()
Zoltan: but the TD spec will have to define the result types of query()
Cristiano: yes, we can use InteractionOutput for now
Publication schedule
Cristiano: how should we do release approach
Cristiano: or should we stop development for TD1.1?
Zoltan: we already have the mechanisms in place
Daniel: agree with that, but the current link is generic
Kaz: We don't need to think about the publication URLs today, but the latest URL will be used by the latest version document. Then the older version documents will be identified by the dated URL (and the history area).
<kaz> e.g., TD history 1.0
Zoltan: Scripting should be able to handle Things with both TD1.1 and TD 2.0 specs
… so we need a single Scripting API to handle both
Cristiano: time is up, call adjourned