I think that’s a good addition. The HNArg would be relatively simple to convert to/from XML, JSON, etc.
-Clarke
From: public-web-and-tv-request@w3.org [mailto:public-web-and-tv-request@w3.org] On Behalf Of Jean-Claude Dufourd
Sent: Tuesday, April 19, 2011 9:53 AM
To: Bob Lund
Cc: Giuseppe Pascale; public-web-and-tv@w3.org; Matt Hammond
Subject: Re: [HOME_NETWORK_TF] Some use cases and requirements for broadcast TV applications
On 19/4/11 17:23 , Bob Lund wrote:
The challenge is - which higher level abstractions get built into the user agent? UPnP is well-defined in terms of services and abstraction of interfaces to those services. MC-DNS based services are not so well defined: the set of services is open ended and the interfaces to the services are service-specific. In this case, it does not seem practical to consider incorporating all the higher level abstractions into the UA.
JCD: Can I reformulate this into "it is not practical to always enforce the higher level abstractions" ?
Is it not optimal to have the two options, the higher level abstraction when the service protocol supports it, and the lower level one when only this is available ?
Let me extend my structured API proposal into:
interface HNMessage {
attribute DOMString name;
attribute DOMString payload;
}
interface HNStructuredMessage extends HNMessage {
attribute HNArg args[];
}
interface HNArg {
attribute DOMString name;
attribute Boolean isInput;
attribute DOMString type;
attribute DOMString value;
}
When the service protocol supports it, the message is a HNStructuredMessage.
When the service protocol does not support it, the message is a plain HNMessage.
Would that not work for you ?
Best regards
JC
--
JC Dufourd
Directeur d'Etudes/Professor
Groupe Multimedia/Multimedia Group
Traitement du Signal et Images/Signal and Image Processing
Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144