1

Topic: Flingo Feature Requests

The Flingo desktop application is a starting point. It's smaller brother Flingo Command-line suffices as a demo and should remain simple, but Flingo Desktop could be much more.

The Flingo desktop and command-line applications start a web server to serve local files off your computer's hard drive and then flings URLs to those files to Flingo-enabled TV widgets. Flingo is powerful because of its minimalism. It relies on only HTTP and JSON, which means it can be integrated into TV widgets that are constrained to a browser or browser-like security sandbox. To play video flung from almost anywhere does not require access to windows file-sharing or NFS or any other filesystems or protocols not generally available from within a browser sandbox.

The Flingo application however is alarmingly bad with regard to usability:

1. I cannot yet right-click on a file in my file system and see a list of TVs to which I can fling a video. This is completely feasible with Windows File Explorer integration, i.e., few changes to the Windows registry.

2. I cannot yet drag-and-drop a file into a folder and have it flung to the TV. Easily achieved by periodically looking at a directory.

3. I cannot yet reorder/skip/remove videos in the queue on the TV. All possible with calls made via Flingo to the TV.

4. Flingo does not yet automatically transcode my video into a format playable on the TV. Look at Handbrake, mencoder or VLC. There are many open source projects that are GPL'd that could be integrated with Flingo Desktop. Most TV's speak H.264, and a default encode with Handbrake will play on a Vizio VIA TV.

If you have any ideas on how to extend the Flingo desktop application or how to use Flingo in other applications then post them here.

2

Re: Flingo Feature Requests

I agree - it would also be good to understand if this will work with online players such as Move Media which powers xfinity, hulu, Youtube, etc.

3

Re: Flingo Feature Requests

dave wrote:

...
3. I cannot reorder/skip/remove videos in the queue on the TV. All possible with calls made via Flingo to the TV.
...

Maybe I'm missing something but this doesn't seem possible with the currently exposed "API".

4

Re: Flingo Feature Requests

AMansfield wrote:

dave wrote:

...
3. I cannot reorder/skip/remove videos in the queue on the TV. All possible with calls made via Flingo to the TV.
...

Maybe I'm missing something but this doesn't seem possible with the currently exposed "API".

My bad.  It is not possible with the APIs documented on flingo.org. Fling supports a generic enqueue message mechanism.  However, I am not yet satisfied that the semantics are what we want, so I delayed documenting them publicly.  At one time I had a more generic RPC mechanism which broke when I made some rather deep changes to the way fling works.

Consider this a request for comments more than true documentation, because it is highly likely to change.

     
    @fling_response
    @restrict_referer
    @annotate(guid=unicode, method=unicode, params=unicode, ttl=int)
    def enqueue_message(self, guid=u'', method=u'', params=None, ttl=600):

You may recognize this for what it is: Python.  All of the APIs on the server-side are written in Python.

Here fling_response, restrict_referer, and annotate are all python decorators.

restrict_referer prevents enqueue_message from being called from anything that has a referer URI containing non-whitelisted domains but allows requests with no referer URI header.  The absence of a referer URI is taken to mean that the message is being sent from a desktop application or bookmarklet.   This assumption is consistent with the behavior of all the modern browsers I tried: Firefox, Safari, IE, Opera, Chrome.  Currently only flingo.tv is whitelisted.  This ensures that arbitrary messages can only be passed via an iframe, web page, or SWF* (see comment #1) served from flingo.tv.  Not even flingo.org is whitelisted.  The restrict_referer decorator enforces the semantics of restricted calls (see http://flingo.org/developers.html#security_model for the definitions of public, private, and restricted calls).  By preventing web sites from sending arbitrary messages to network services, we prevent random web sites from doing things like removing queued items, queueing up spam, etc.  The iframe, web page, or SWF served from a trusted domain acts as a trusted intermediary that can enforce policy.

fling_response encodes anything returned as JSON.

annotate converts the string parameters in the URI query string to the appropriate type and raises an exception when the conversion fails.

guid if omitted causes the message to be private broadcast to all services in the user's private network.  If specified then the message is delivered to only that specified network service.

params is a JSON-encoded dict of key-value pairs where the value can be anything representable using JSON including arrays, dicts, and nested arrays and dicts.

Comment #1: I put an asterisk next to SWF because browsers handle referer URIs inconsistently for Flash.  As a result, I have been playing with other mechanisms to secure flash such as requiring messages to sent using HTTP POSTs since most cross-site scripting hacks use HTTP GET  (SCRIPT, IFRAME, IMG).

WEAKNESSES:

  • only supports short messages since the params are encoded in the URI.

  • no ability to specify service name, so if two services run on a device and share GUID then there is no way to address one specific service.

  • requires rather weird special encoding for params.

  • does not work with any existing standard RPC libraries.

PROPOSED FIX:

  • deprecate passing params or method via URI.

  • use the URI as an envelope to specify destination GUID(s) and/or service names only.  If none provided then treat as private broadcast to all services in the user's private network.

  • require messages to be POSTed.

  • The POST body uses JSON-RPC.

By using JSON-RPC, a wide variety of existing libraries can be used to talk to devices.  To separate call from envelope, use the the URI of the RPC interface to scope the call to a specific device (guid), named service on that device (guid, service name pair) or named service on all devices (service name).  Something like:

   http://flingo.tv/fling/enqueue_message?guid=G&service=xyzmusicplayer

with body

  {"params": {"a": 10, "b": "boo"}, "jsonrpc": 2.0, "method": "foo", "id" : 0}

flingo.tv queues the message in a relay.  It may queue the message to multiple destinations, e.g., when guid is not provided in the call's envelope and there are multiple services in the network.  Currently service(s) obtain queued messages by long-polling.

    @fling_response
    @restrict_referer
    @annotate(guid=unicode, wait=int)
    def longpoll_messages(self, guid=u'', wait=60):

The server holds onto the request for a maximum of wait seconds.  It returns immediately with an array of messages if any were queued since the last call to longpoll_messages.

Still not completely clear how to handle return results when multiple services receive a single queued message.  Nothing would strictly adhere to the defined semantics of JSON-RPC.  One solution is to always return an array of dicts where each dict contains a result and the envelope (guid and/or service name) of the service returning the result.

I would like to extend longpoll to include a service name parameter so that each service running on a device can obtain messages addressed only for that service.

5

Re: Flingo Feature Requests

dmascus wrote:

I agree - it would also be good to understand if this will work with online players such as Move Media which powers xfinity, hulu, Youtube, etc.

Clearly any of these players can generate HTTP requests and JSON libraries are available in almost any language and easily writable when not. 

I see no reason why sites could not integrate fling with online flash players.   In fact this is the intenthttp://youtubesocial.com already demonstrates flinging Youtube videos from a Flash player.  There is no reason why Youtube could not use the same integration.

Similarly, any browser that speaks HTML 5, should be able to present a video player and use flingo.

Move Media is not widely supported in TVs or set-top boxes and as such this seems a little less likely.

6

Re: Flingo Feature Requests

How do you fling from Youtube social to WD TV?

dave wrote:
dmascus wrote:

I agree - it would also be good to understand if this will work with online players such as Move Media which powers xfinity, hulu, Youtube, etc.

Clearly any of these players can generate HTTP requests and JSON libraries are available in almost any language and easily writable when not. 

I see no reason why sites could not integrate fling with online flash players.   In fact this is the intenthttp://youtubesocial.com already demonstrates flinging Youtube videos from a Flash player.  There is no reason why Youtube could not use the same integration.

Similarly, any browser that speaks HTML 5, should be able to present a video player and use flingo.

Move Media is not widely supported in TVs or set-top boxes and as such this seems a little less likely.

7

Re: Flingo Feature Requests

dmacus wrote:

How do you fling from Youtube social to WD TV?

Click on "find a video" near the bottom of the page  (design flaw).

Enter something to search for then select a video.

In the upper-righthand corner, the blue fling button appears.  Push this  button and the video should appear in your queue on your TV.

8

Re: Flingo Feature Requests

thanks - it was obscured by some disclaimer that needed to be closed on the top of the viewer