Re: [HOME_NETWORK_TF] Implementation Alternatives

Here is my take on an interface, difficult to split in discovery and 
communication.
I adopt a structure closer to Dave's with callbacks. I introduce a 
method exposing a service to the outside, and a structured object for 
the message and its arguments.
I am not sure what syntax to use to declare attributes with a function 
as value (for callbacks).

interface HNControl {

         readonly attribute DOMString supportedProtocols[];

         // static list of supported protocols

         readonly attribute HNService discoveredServices[];

         // dynamic list of all discovered services in this session

         void activateServiceDiscovery(HNDiscoverer disc);

         // call this function with null to stop discovery

         HNService createService(protocol, name, type, description, HNMessage set[]);

         // this method creates a service provided by this "page"

         // the array of HNMessage defines the interface of the service

         // only the sendMessage and receiveMessage of the returned HNService are useful

}

interface HNDiscoverer {

         attribute function discoverService;

         // callback with one parameter of type HNService

}

interface HNService {

         readonly attribute DOMString name;

         readonly attribute DOMString type;

         readonly attribute DOMString address;

         readonly attribute DOMString description;

         integer sendMessage(HNMessage msg);

         attribute function receiveMessage;

         // callback with one parameter of type HNMessage

         attribute function serviceAvailability;

         // callback with one parameter of type Boolean

}

interface HNMessage {

         attribute DOMString name;

         attribute HNArg args[];

}

interface HNArg {

         attribute DOMString name;

         attribute Boolean isInput;

         attribute DOMString type;

         attribute DOMString value;

}



On 15/4/11 00:10 , Clarke Stevens wrote:
>
> I have posted a new document for implementation alternatives. The 
> purpose of the document is to provide example use cases and various 
> ways to implement the use cases. This is NOT intended as the 
> comprehensive use case list. It is meant to provide a few key use 
> cases that illustrate fundamental architectural examples and how they 
> would be implemented under various architectural models.
>
> My hope is that this will drive discussion and point out the relative 
> strengths and weaknesses of different approaches in order to guide us 
> to a good solution.
>
> You can find the document with a couple of initial examples here:
>
> http://www.w3.org/2011/webtv/wiki/Alternatives
>
> You can also get to it from the "Open Discussions" link on the main 
> HNTF page.
>
> Thanks,
>
> -Clarke
>


-- 
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