W3C home > Mailing lists > Public > public-web-and-tv@w3.org > May 2011

[HOME_NETWORK_TF] Minutes of TF call 2011-05-31

From: Giuseppe Pascale <giuseppep@opera.com>
Date: Tue, 31 May 2011 19:30:20 +0200
To: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Message-ID: <op.vwcv8uo86ugkrk@laptop>
Hi all,
minutes from our last call; thanks to Matt for scribing.

/g

====
<scribe> scribe: Matt Hammond
<scribe> scribenick: MattH

giuseppe: will start with open issues
<giuseppe> http://www.w3.org/2011/webtv/track/products/2
<giuseppe>   
http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Requirements#Definitions

##Topic: Definition section in requirement document

giuseppe: but first 'definitions' section
MattH: programme does need clarifying
giuseppe: distinction between tv and companion not necessary? all just as  
important?
MattH: definition points out use of broadcast, not just streaming

##Topic: issue 4

<trackbot> ISSUE-4 -- Use Case: Service User Interface -- open
<trackbot> http://www.w3.org/2011/webtv/track/issues/4

giuseppe: next on agenda: open issues
  ... different groups using different approaches to grouping requirements
  ... which should we use?
rberkoff: issue-17 - why not reference HTML5?
jcdufourd: there's CEA2014 - not just HTML5
rberkoff: support backporting - capture as requirement?
mav: too early to be a fixed requirement for older HTML version - leave up  
to WGs

##Topic: Usecases format

<jcdufourd> here is the DAP sample:   
http://www.w3.org/TR/2011/NOTE-dap-policy-reqs-20110317/#interactions

giuseppe: what choice of use case fomats - other WGs do differently
rberkoff: we seem to be changing our minds for use case template?
  ... thought we were going to try supplementing existing use-cases not  
reformatting?
  ... need more time to consider


giuseppe: issue-4 subsumed by issue-17, close it?
rberkoff: action to rewrite 17
giuseppe: will post proposal on requirement document on mailing list,  
including issue 4 issues

##Topic: Issue-7

<trackbot> ISSUE-7 -- Use case: Service Migration -- open
<trackbot> http://www.w3.org/2011/webtv/track/issues/7

MattH: not clear why radio service needs to migrate. can't the UI transfer  
state between services?

jcdufourd: radio service could have no UI. salient part that gets moved is  
the state
  ... service needs to migrate because the UI (radio controller) needs to  
have seen the service in the new location

rberkoff: use case is to actually just migrate state information between  
services
  ... interesting detail: buffering needed if migrating playback between  
devices to avoid the user missing a chunk

mark: migrating can be more of an application specific function rather  
than browser function, particularly for game state

jcdufourd: will need to reestablish connections between gaming devices if  
the gaming device changes. state info needs to include connection states  
(hence inclusion)

giuseppe: browser might facilitate transfer of state info without  
understanding it

mark: different games need to behave differently whilst transfer taking  
place - application specific

giuseppe: use case covers transfer of state where no server is involved

giuseppe, mav: where server involved, this use case is not necessary

##Topic: final remarks

giuseppe: encourage everyone to discuss via email

-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden
Received on Tuesday, 31 May 2011 17:30:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 31 May 2011 17:30:56 GMT