35.3Contributions
Session
|
Number
|
Title
|
Source
|
Scene
|
m16577
|
MPEG-U WD 1.1
|
Jean-Claude Dufourd
|
Scene
|
m16578
|
MPEG-U WD improvements and proposals
|
Jean-Claude Dufourd
Cyril Concolato
Jean Le Feuvre
Kyungmo Park
Seoyoung Wang
Jaeyeon Song
|
Scene
|
m16644
|
MPEG-U Howto, for inclusion as an informative annex
|
Jean-Claude Dufourd
Cyril Concolato
Jean Le Feuvre
|
Scene
|
m16726
|
MPEG-U improvements for widget security
|
Kyungmo Park
|
M16578:
Improvements and proposals.
The contribution proposes:
- an mw:serviceProvider attribute to be added to the mw:interface element. Accepted.
- context-related additions:
- mw:contextInformation element: accepted.
- mw:contextConfiguration element with the following attributes:
- saveTrigger: accepted.
- restoreTrigger: accepted.
- saveAction: accepted with a change of definition to:
"Optional. Indicates the name of a scene construct that is activated once the context has been saved."
- restoreAction: accepted with a change of definition to:
"Optional. Indicates the name of a scene construct that is activated once the context has been restored."
- type (persistent | transient): the idea is accepted but the implementation is modified as follow. The attribute is renamed "migratable". It is moved as an extension to the preference element. Its values are changed to: 'true', meaning that the associated preference value shall be transferred when the widget changes widget manager; 'false' meaning that the associated preference value shall not be transferred as part of the context information when the widget changes widget manager.
- extension to the W3C preference element: mw:connectTo attribute: accepted.
- URL syntax for context information retrieval: accepted but with two remarks:
- it should be noted that if the initial widget manager has enough resources or credentials, it may modify the preference elements in the manifest to send the context information. This may be too expensive and we may need a way to reference a side context information file along with the manifest (to be investigated);
- the solution not prevent a widget manager from sending the context information in a "higher-level" package (multipart/related mime package).
We should add the following clarification:
"In case of widget mobility, the source widget manager should provide a base url to retrieve the widget package for a given widget instance and should support requests for the associated context information of that instance in the form of ?mpeg-u-context if the base url does not contain '?' or &mpeg-u-context if it already contains a '?'."
- widget aggregation: mw:component and mw:requiredInterfaces elements and associated API: accepted.
- multiple instances: mw:multiBind attribute: accepted but renamed to mw:multipleBindings.
- temporary widgets: mw:discardable attribute: accepted but the definition is changed to:
"This optional Boolean attribute has a default value of false. It indicates whether the widget shall be discarded by the widget manager after its deactivation and shall no longer be used by the widget manager."
Fixes:
- default on input/output: accepted
- xml prefixes: accepted
- IDL fixes: accepted
- obsolete predefined communications: accepted to remove the text.
- alignment with W3C: accepted
- mw:interface@type: the idea is accepted. We need to have clear, normative behaviour defining when you can accept or reject a service.
- component positioning: needs more discussion. Without this tool, the aggregation of widget will just concern the dependencies between widgets but one will not be able to present the widgets in an aggregated manner.
Dostları ilə paylaş: |