taskGnash - The GNU Flash player - Tasks: task #5919, Define a communication protocol...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #5919: Define a communication protocol between player and other processes

Submitter:  Sandro Santilli <strk>
Submitted:  Sat 23 Sep 2006 04:13:31 PM UTC
   
 
Should Start On:  Thu 01 Apr 2010 06:00:00 AM UTC Should be Finished on:  Mon 01 Aug 2011 06:00:00 AM UTC
Category:  None Priority:  7 - High
Status:  Done Privacy:  Public
Assigned to:  rsavoye Percent Complete:  100%
Open/Closed:  Closed Effort:  0.00

Jump to the original submission

Mon 26 Jul 2010 01:47:57 PM UTC, comment #17: 

Close enough to being done to close this task. Anything left is a bug report.

Rob Savoye <rsavoye>
Group administrator
Mon 19 Jul 2010 08:33:42 PM UTC, comment #16: 

We need a 98% complete setting... As of revno #12316, the commands SetVariable, GetVariable, IsPlaying, PercentLoaded, Play, Rewind, TotalFrames, and StopPlay work. This only leaves calling remote methods, and supporting Pan/Zoom/SetZoomRect before being complete.

Rob Savoye <rsavoye>
Group administrator
Fri 21 May 2010 01:32:29 AM UTC, comment #15: 

Arg, there is no 95% complete menu item. As of revno #12193, the communication protocol is complete. XML messages in the documented Adobe format are sent between the plugin and the player. The player correctly parses the messages, All that is remaining is to call the methods, and to actually set the variables set by JavaScript.

Rob Savoye <rsavoye>
Group administrator
Mon 19 Apr 2010 09:46:48 PM UTC, comment #14: 

I've added the communication protocol, which is an XML based one. The Gnash implementation is based on documentation on the Adobe protocol, not that it probably matters.

Rob Savoye <rsavoye>
Group administrator
Mon 27 Oct 2008 02:55:04 PM UTC, comment #13: 

Benjamin added a POST command now.

Seems pretty much time to document the protocol so far
somewhere. I think a related page of Doxygen would be
good for this, possibly written where used (movie_root.cpp?)

Sandro Santilli <strk>
Group Member
Fri 04 Apr 2008 10:31:46 PM UTC, comment #12: 

I'm new to protocols definition. What we need here is a CALL
interface, so client sends a request, and receives a response.
we don't always need a response, so that might be dependent
on the kind of request.

Also, we must support initiating the char on both ends,
sometime can be Javascript calling Flash function, sometime
the other way around..

For now, we are using a one-way channel (host-to-gnash),
so that needs to change too.





Sandro Santilli <strk>
Group Member
Fri 04 Apr 2008 03:36:18 PM UTC, comment #11: 

I'd suggest a simple XML based protocol so it can potentially be used from swf based applications as well for extra functionality. One thought is maybe this could be simpler if we write a Firefox extension to talk to Gnash. The extension would handle talking to JavaScript.

Rob Savoye <rsavoye>
Group administrator
Fri 04 Apr 2008 03:06:19 PM UTC, comment #10: 

Just a note, INVOKE was also added.. so we're up to:

 GET <target>:<url>\n
 INVOKE <command>:<arg>\n

We'll need two-way communication for CALL (fscommand2)
and generic host-to-gnash (javascript calling flash)

Sandro Santilli <strk>
Group Member
Mon 17 Mar 2008 11:06:35 AM UTC, comment #9: 

We need to define a format for POST requests too,
see bug #22257

Sandro Santilli <strk>
Group Member
Wed 30 Jan 2008 09:52:47 PM UTC, comment #8: 

I committed the second patch too.
Now, the next major task here is to actually define the protocol.
The current code is very lame, as it considers anything
after the first "GET " string read from the socket as an url.
This includes subsequent "GET " requests too...

So, we'd either need a separator (and then escaping) or an header.
An header specifying lenght might be simpler.

Using a separator might also be ok (with newline being a good candidate) as long as we make sure to escape them

Sandro Santilli <strk>
Group Member
Wed 30 Jan 2008 09:20:39 PM UTC, comment #7: 

pluginPipe2.patch addresses the 100% CPU usage on gnash death.
For the javascript could you attach a testcase ?

(file #14906)

Sandro Santilli <strk>
Group Member
Wed 30 Jan 2008 07:47:05 PM UTC, comment #6: 

Javascript pseudo URLs need splitting at 'javascript:', then it works fine. Youtube included, but it doesn't resize to fit the window.

Killing gnash (or if it dies on its own) while it's running in the browser gives high CPU usage; that goes away when you leave the webpage (i.e. when the plugin instance itself is destroyed).

Benjamin Wolsey <bwy>
Group Member
Wed 30 Jan 2008 06:51:13 PM UTC, comment #5: 

The pipe-switch patch is already in head,
this other patch enables it's use from the NPAPI plugin.
It will only handle GET requests, with no target.
Didn't test javascript urls, nor I did implement targets.

Anyway my initial tests shows it to work fine at least in
avoiding to open lots of different windows for sites using
flash navigation.

A good example is:
http://www.ferryhalim.com/orisinal/

Another one is:
http://www.uptoten.com

Your testing is higly welcome, successfull tests would
convince me to commit this.

(file #14905)

Sandro Santilli <strk>
Group Member
Wed 30 Jan 2008 12:31:01 AM UTC, comment #4: 

Jeroen Wijering's popular player depends on this.

Bastiaan Jacques <bjacques>
Group Member
Tue 15 Jan 2008 07:17:01 PM UTC, comment #3: 

Hooking into the gecko loop is fairly easy. At least on Linux, gecko uses glib, so you can just add a hook to the glib main loop (see glib docs).

I don't know if glib is also used on Windows (but I suspect not).

Bastiaan Jacques <bjacques>
Group Member
Mon 14 Jan 2008 05:09:09 PM UTC, comment #2: 

The attached patch implements a -F <num> switch to the standalone player setting the filedescriptor number to write browser requests to. If given url requests will be written there as:

  GET <url> <target>\n

Next step would be creating the pipe and read the data from
the plugin, which turned out not to be straightforward
(need to find out how to hook on the gecko main loop, forking
and executing a listener loop won't work with NPN_GetURL calls)

(file #14796)

Sandro Santilli <strk>
Group Member
Sat 17 Nov 2007 10:41:25 AM UTC, comment #1: 

Also the other way around is needed, which is allowing a process (for instance the plugin) to request the player process to do something, like setting variables from JavaScript.

Sandro Santilli <strk>
Group Member
Sat 23 Sep 2006 04:13:31 PM UTC, original submission:  

The gnash standalone process must request some operations to a browser, when available. In particular, getURL operations (with GET and POST method) must be externally requested.

OpenVRML is using a similar mechanism:
http://openvrml.cvs.sourceforge.net/openvrml/openvrml/mozilla-plugin/src/openvrml.cpp?revision=1.37&view=markup

Sandro Santilli <strk>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #14906:  pluginPipe2.patch added by strk (9KiB - text/x-patch)
file #14905:  pluginPipe.patch added by strk (8KiB - text/x-patch - adds support in the plugin for reading player requests)
file #14796:  pipe-switch.patch added by strk (7KiB - text/x-patch)

 

Carbon-Copy List
  • -email is unavailable- added by strk
  • -email is unavailable- added by rsavoye (Posted a comment)
  • -email is unavailable- added by bwy (Posted a comment)
  • -email is unavailable- added by strk (as for discussion over bug #17586)
  • -email is unavailable- added by strk (Posted a comment)
  • -email is unavailable- added by bjacques (Updated the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 22 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-26 rsavoye StatusIn Progress Done
        Percent Complete90% 100%
        Open/ClosedOpen Closed
    2010-07-19 rsavoye Should be Finished on2010-05-31 2011-08-01
    2010-05-21 rsavoye Should Start On2006-09-22 2010-04-01
        Should be Finished on2006-09-22 2010-05-31
    2010-04-19 rsavoye Percent Complete30% 90%
        Assigned tostrk rsavoye
    2008-10-27 strk Carbon-Copy- Added bwy
    2008-10-27 strk Percent Complete0% 30%
    2008-03-17 strk Dependencies- bugs #22257 is dependent
    2008-01-30 strk Attached File- Added pluginPipe2.patch, #14906
    2008-01-30 strk Attached File- Added pluginPipe.patch, #14905
    2008-01-30 strk StatusNone In Progress
        Assigned tobjacques strk
    2008-01-30 bjacques Priority1 - Later 7 - High
    2008-01-14 strk Dependencies- bugs #21155 is dependent
    2008-01-14 strk Carbon-Copy- Added annonygmouse
    2008-01-14 strk Attached File- Added pipe-switch.patch, #14796
    2007-11-17 strk SummaryDefine a communication protocol for browser requests Define a communication protocol between player and other processes
    2007-04-01 bjacques Assigned toNone bjacques
    2006-10-19 strk Dependencies- bugs #17586 is dependent

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code