On Wed, Aug 26, 2009 at 5:49 PM, Kirk Bateman<[email protected]> wrote:
> I suppose something similar to the havi work could be helpful. Effectively
> store java applications or similar on the device to be controlled and
> download them to the remote to give the user interface.

This is similar to Fabio's point in the previous mail, re device
exporting UI to the mobile, so I'll reply to both in one go...

I didn't mention it in my earlier post but there has also been some
work done in this direction in the Web  accessibility community - eg
see http://trace.wisc.edu/docs/2003-CHI-Unified-Remote-Console-Standard/
and http://www.incits.org/tc_home/v2.htm  ... which has some
pay-to-see standards, and a summary whitepaper
http://myurc.org/whitepaper.php

I don't know a lot about it, but I had some discussions with Gottfried
Zimmermann a few years ago, I think they were using Mozilla XUL then,
and now it seems investigating XForms. I'd also throw W3C's Widget
specifications into the mix here as another form of mini-app that has
support from eg. Nokia, Vodafone, if not yet showing on the gphone or
iphone.

These all seem worthwhile, but I'd hope that a basic core could be
more declarative: state of the playing video, operations that navigate
through the content, metadata about other shows etc. While iphones etc
have limited CPU they're getting faster all the time, so it seems a
shame if such fancy devices are being used purely as a remote UI for
the TV. In addition the phone may know things about its owner (eg.
viewing preferences) which aren't common knowledge or available to the
media player. We are going to be looking at profile-to-content
matching, and it isn't clear there where such matching best takes
place.

> Could use discovery features to show if the device contains an app for
> controlling it otherwise possibly something similar to data forms.

Good idea...

> However, how are you thinking of streaming the media you want to control ?
> Jingle ? Or is this more for controlling something that is already being
> output to a destination ?

Mostly the latter (both for home media centre type apps, but also
browser-based Web video - both need remotes). That said -  if the
device is capable of streaming to Jingle, why not expose that too.
Might be nice for the hard-of-hearing to get the audio piped to their
headphones, but this would be scope creep and I'm not sure about
sync'ing issues etc.

Jingle also might have some promise for the reverse direction - eg.
I'm watching a documentary or news report, I pause it on my phone and
make an annotation by audio recording into my device, which then gets
linked back into the content if the media server accepts incoming
audio annotations. But then it could just as well be posted to the Web
if a suitable service was configured...

cheers,

Dan


> Regards
>
> Kirk Bateman
>
>
> Sent from my iPod
>
> On 26 Aug 2009, at 16:41, Fabio Forno <[email protected]> wrote:
>
>> On Wed, Aug 26, 2009 at 5:24 PM, Dan Brickley<[email protected]> wrote:
>>>
>>> Hi Dirk,
>>>
>>> (Cc:'ing the XMPP Social list, ... to be , well, social. And in case
>>> others are interested...)
>>>
>>> We talked briefly at FOSDEM during the q/a for your presentation on
>>> the XMPP day. I was wondering if you'd be interested to collaborate on
>>> specs for remote control APIs mediated by XMPP. I understand you've
>>> been focussing mainly on cross-cutting infrastructural issues
>>> (security, device pairing and authentication).
>>
>> [...]
>>
>> Quick reply for just saying that here at bluendo we are very
>> interested in this topic, since we think that  mobile terminals will
>> become more and more the remote control of anything. Beside
>> infrastructure and APIs we'd like to focus on user interfaces too,
>> since we don't think that the approach of building an ad hoc ui for
>> any type of device is scalable; instead we think that the device
>> should be able to export the GUI to the mobile, with something similar
>> to ad hoc commands.
>>
>> --
>> Fabio Forno, Ph.D.
>> Bluendo srl http://www.bluendo.com
>> jabber id: [email protected]
>

Reply via email to