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

Submitted by:  Sandro Santilli <strk>
Submitted on:  Sat 23 Sep 2006 04:13:31 PM UTC  
 
Should Start On: Thu 01 Apr 2010 06:00:00 AM UTCShould be Finished on: Mon 01 Aug 2011 06:00:00 AM UTC
Category: NonePriority: 7 - High
Status: DonePrivacy: Public
Percent Complete: 100%Assigned to: Rob Savoye <rsavoye>
Open/Closed: ClosedEffort: 0.00

(Jump to the original submission 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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project 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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project 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>
Project 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>
Project 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>
Project 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>
Project Member
Wed 30 Jan 2008 12:31:01 AM UTC, comment #4:

Jeroen Wijering's popular player depends on this.

Bastiaan Jacques <bjacques>
Project 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>
Project 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>
Project 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>
Project 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>
Project Member

 

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)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 19 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 26 Jul 2010 01:47:57 PM UTCrsavoyeStatusIn Progress=>Done
      Percent Complete90%=>100%
      Open/ClosedOpen=>Closed
    Mon 19 Jul 2010 08:33:42 PM UTCrsavoyeShould be Finished onMon 31 May 2010 06:00:00 AM UTC=>Mon 01 Aug 2011 06:00:00 AM UTC
    Fri 21 May 2010 01:32:29 AM UTCrsavoyeShould Start OnFri 22 Sep 2006 10:00:00 PM UTC=>Thu 01 Apr 2010 06:00:00 AM UTC
      Should be Finished onFri 22 Sep 2006 10:00:00 PM UTC=>Mon 31 May 2010 06:00:00 AM UTC
    Mon 19 Apr 2010 09:46:48 PM UTCrsavoyePercent Complete30%=>90%
      Assigned tostrk=>rsavoye
    Mon 27 Oct 2008 02:55:04 PM UTCstrkCarbon-Copy-=>Added bwy
    Mon 27 Oct 2008 02:55:03 PM UTCstrkPercent Complete0%=>30%
    Wed 30 Jan 2008 09:20:39 PM UTCstrkAttached File-=>Added pluginPipe2.patch, #14906
    Wed 30 Jan 2008 06:51:13 PM UTCstrkAttached File-=>Added pluginPipe.patch, #14905
    Wed 30 Jan 2008 11:57:27 AM UTCstrkStatusNone=>In Progress
      Assigned tobjacques=>strk
    Wed 30 Jan 2008 12:31:01 AM UTCbjacquesPriority1 - Later=>7 - High
    Mon 14 Jan 2008 05:11:05 PM UTCstrkCarbon-Copy-=>Added annonygmouse
    Mon 14 Jan 2008 05:09:09 PM UTCstrkAttached File-=>Added pipe-switch.patch, #14796
    Sat 17 Nov 2007 10:41:25 AM UTCstrkSummaryDefine a communication protocol for browser requests=>Define a communication protocol between player and other processes
    Sun 01 Apr 2007 12:17:23 PM UTCbjacquesAssigned toNone=>bjacques

    Back to the top


    Powered by Savane 3.1-cleanup1