Fwd: Suggestion for the gap analysis of R9

Dear all,

I'm Soobin Lee of KAIST in Korea.

Thanks to Futomi's great exertions, I think that our BG document have
been well-organized.

In addition, I'm suggesting the gap analysis part of 'R9.
Synchronizing contents', which is omitted in the current version, as
follows.

-------------------
To synchronize contents on the signage and other devices such as
users' smartphones and tablets, there are two ways available. One way
is to employ a server between the signage and the devices. Using the
WebSocket API and web server program implemented by an appropriate
framework such as node.js, events or contents on the signage can be
delivered to the others through the server.
Another way is based on the direct communication among web browsers,
browsers of a signage and a user's device in this case, which has
several advantages in public space. It can facilitate instant and
temporal exchanges of dynamic events or contents for users near the
signage. The current state-of-art, however, do not support
communication between browsers. Though IETF Rtcweb workgroup
(http://tools.ietf.org/wg/rtcweb/charters) and W3C WebRTC workgroup
(http://www.w3.org/2011/04/webrtc-charter.html) are covering this
issue, it is in the experimental stage. Recently, google chromium
project has proposed an extension API set to enable the browser's tap
contents to be captured and transmitted using
WebRTC("chrome.experimental.capture.getTabMedia",
"chrome.experimental.capture.onTabCaptured", and
"chrome.experimental.capture.getCapturedTabs").

The WebSocket API (http://www.w3.org/TR/websockets/)
WebRTC (http://www.w3.org/TR/webrtc/)
WebRTC Tab Content Capture API
(http://www.chromium.org/developers/design-documents/extensions/proposed-changes/apis-under-development/webrtc-tab-content-capture)
-------------------

I think my suggestion can also be included in R16(capturing a screen
shot) partially.

Any suggestions or comments are welcome.

Thanks.

Best regards,

Soobin Lee, Team Leader / Research Professor / Ph.D.
Knowledge Convergence Team
KAIST Institute for Information Technology Convergence
335 Gwahangno, Yuseong-gu, Daejeon, 305-701, Republic of Korea
Tel: +82-42-350-7110
E-mail: soobinlee@itc.kaist.ac.kr, caes81@gmail.com



---------- Forwarded message ----------
From: Futomi Hatano <futomi.hatano@newphoria.co.jp>
Date: 2012/10/21
Subject: Re: Suggestion for the gap analysis of R9
To: Soobin Lee <soobinlee@itc.kaist.ac.kr>
참조: internal-websignage@w3.org


Dear Soobin,

Thank you so match for your suggestion.
I'm very happy to fill the gap analysis of R9.
Your suggestion is very important, I think your effort should be open
to the public.
(This mailing list archive is available to only the BG members.)
If you don't mind, could you send your suggestion to the public
mailing list (public-websignage@w3.org) again?

Best regards,
Futomi

On Sun, 21 Oct 2012 10:31:38 +0900
Soobin Lee <soobinlee@itc.kaist.ac.kr> wrote:

> Dear all,
>
> I'm Soobin Lee of KAIST in Korea.
>
> Thanks to Futomi's great exertions, I think that our BG document have
> been well-organized.
>
> In addition, I'm suggesting the gap analysis part of 'R9.
> Synchronizing contents', which is omitted in the current version, as
> follows.
>
> -------------------
> To synchronize contents on the signage and other devices such as
> users' smartphones and tablets, there are two ways available. One way
> is to employ a server between the signage and the devices. Using the
> WebSocket API and web server program implemented by an appropriate
> framework such as node.js, events or contents on the signage can be
> delivered to the others through the server.
> Another way is based on the direct communication among web browsers,
> browsers of a signage and a user's device in this case, which has
> several advantages in public space. It can facilitate instant and
> temporal exchanges of dynamic events or contents for users near the
> signage. The current state-of-art, however, do not support
> communication between browsers. Though IETF Rtcweb workgroup
> (http://tools.ietf.org/wg/rtcweb/charters) and W3C WebRTC workgroup
> (http://www.w3.org/2011/04/webrtc-charter.html) are covering this
> issue, it is in the experimental stage. Recently, google chromium
> project has proposed an extension API set to enable the browser's tap
> contents to be captured and transmitted using
> WebRTC("chrome.experimental.capture.getTabMedia",
> "chrome.experimental.capture.onTabCaptured", and
> "chrome.experimental.capture.getCapturedTabs").
>
> The WebSocket API (http://www.w3.org/TR/websockets/)
> WebRTC (http://www.w3.org/TR/webrtc/)
> WebRTC Tab Content Capture API
> (http://www.chromium.org/developers/design-documents/extensions/proposed-changes/apis-under-development/webrtc-tab-content-capture)
> -------------------
>
> I think my suggestion can also be included in R16(capturing a screen
> shot) partially.
>
> Any suggestions or comments are welcome.
>
> Thanks.
>
> Best regards,
>
> Soobin Lee, Team Leader / Research Professor / Ph.D.
> Knowledge Convergence Team
> KAIST Institute for Information Technology Convergence
> 335 Gwahangno, Yuseong-gu, Daejeon, 305-701, Republic of Korea
> Tel: +82-42-350-7110
> E-mail: soobinlee@itc.kaist.ac.kr, caes81@gmail.com

--
Newphoria Corporation
Chief Technology Officer
Futomi Hatano
--
futomi.hatano@newphoria.co.jp
http://www.newphoria.co.jp/

Received on Tuesday, 23 October 2012 18:11:05 UTC