Sat 05 Mar 2011 08:39:30 PM UTC, comment #11:
The test uses an xml received by our plugin from youtube, as shown by the backtrace attached to this ugly bug here:
https://savannah.gnu.org/bugs/index.php?31766#comment10
|
Sat 05 Mar 2011 05:35:40 PM UTC, comment #10:
The plugin shouldn't be using any headers from Gnash core. I see only StringPredicates.h and GnashSystemIOHeaders.h, which I guess are safe. AS3 did add more functionality to the API. But the point is I don't believe ExternalInterface is supposed to ever handle nested tags, so this bug report could be bogus, and based on a broken test case.
|
Sat 05 Mar 2011 05:30:09 PM UTC, comment #9:
plugin.cpp does in fact use some headers from libbase/.
Anyway, it looks to me as if the ExternalInterface (according to specification) permits controlling actionscript via the XML invoke specfication which we are using, but only in AS3. AS2 just defines the call() and addCallback() methods. Please correct me if I'm wrong.
I think it is safe to resolve this as postponed until we change the plugin and/or when we implement AS3.
|
Sat 05 Mar 2011 05:15:17 PM UTC, comment #8:
Currently the plugin uses no headers from the rest of gnash. The debug functions are actually different, just have the same names.
Sharing header only code for XML parsing is fine, it just isn't a big saving in code. You're welcome to implement such a thing if you want, but as ExternalInterface is currently working fine with the new YouTube API, it seems there are more important things to be working on. Maybe it's time for somebody to start on a real plugin. Adobe uses ExternalInterface for the flash debugger, which is the entire reason it's an XML networking protocol.
|
Sat 05 Mar 2011 05:06:04 PM UTC, comment #7:
rsavoye, what I was suggesting was putting the XML parsing code in a header file, which can be compiled into plugin code like other headers from libbase/ presently are.
But it seems wasteful to spend time on this if the plugin <-> Gnash communication itself is going to be irrelevant when we put Gnash itself into the browser namespace as a real plugin.
I am certainly not convinced ExternalInterface is a useful way to remotely control Gnash.
|
Sat 05 Mar 2011 04:53:11 PM UTC, comment #6:
EsxternalInterface doesn't pass JavaScript at all, only the XML messages as specified by the Adobe spec. Even with a traditional style plugin, we'd still want the optional ability to use a network to remotely control Gnash when running standalone. I don't think ExternalInterface is supposed to deal with nested tags, the test case could be trying to test functionality that may never been required. Before talking about how ExternalInterface works, it'd be easier if people actually researched this first.
|
Sat 05 Mar 2011 04:43:52 PM UTC, comment #5:
That's what needs to be done for the ExternalInterface implementation; it would both simplify the code handling it and achieve much better compatibility. The plugin should just be passing XML (and possibly JavaScript; I haven't checked the details recently) to a couple of native functions, which then distribute it to the appropriate built-in AS functions.
But the 'invoke' notion doesn't just handle ExternalInterface, but also some other things like getURL and quitting, which would need to be separated out.
A good time to do this would be when writing a real plugin, because then the fd reading becomes superfluous anyway.
|
Sat 05 Mar 2011 04:41:38 PM UTC, comment #4:
The plugin shouldn't have any dependencies on core Gnash code unless we ever create a traditional style plugin. While it might be possible to use XML_as.cpp on the Gnash side, the XML used for the ExternalInterface messages in the plugin is much simpler, and deals with NPVariants, instead of ActionScript objects.
|
Sat 05 Mar 2011 04:37:39 PM UTC, comment #3:
Thanks.
I'm curious why there is XML parsing logic in external.{h,cpp}; wouldn't it make sense to stick the XML parsing code from XML_as.cpp (or even from some external XML parsing library) in libbase/ and use that to parse the invoke requests?
|
Sat 05 Mar 2011 03:38:06 PM UTC, comment #2:
It's plugin/npapi/test.cpp. There are two sets of files required for EsternalInterface to work, the plugin side in plugin/npapi, and the Gnash side in libcore.
|
Sat 05 Mar 2011 03:35:50 PM UTC, comment #1:
Does ExternalInterface refer to libcore/ExternalInterface.{h,cpp} or to plugin/npapi/external.{h,cpp}, or both?
Where do I find test.c?
|
Thu 10 Feb 2011 09:16:55 AM UTC, original submission:
As shown by test.c, the parseArguments function fails when one of the arguments is an object (ie: contains sub-elements)
|