RE: [HOME_NETWORK_TF] Implementation Alternatives

Jean-Claude,

I have a question about this approach. You have a createService() action under HNControl. Is the intention to create a service within a web page that could be discovered? I can see how this might be used for a rendering service, but it doesn't seem to make sense for something like a content directory service (due to security issues with local files, transient nature of a web page, browser client acting as server, etc.). I'm not sure I'm interpreting this correctly, so could you clarify?

Thanks,
-Clarke

From: public-web-and-tv-request@w3.org [mailto:public-web-and-tv-request@w3.org] On Behalf Of Jean-Claude Dufourd
Sent: Friday, April 15, 2011 5:58 AM
To: public-web-and-tv@w3.org
Subject: 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