incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Change to Plugins introduced in Android
Date Mon, 21 Nov 2011 21:06:11 GMT


On 11-11-16 1:47 PM, "Patrick Mueller" <pmuellr@gmail.com> wrote:

>On Thu, Nov 10, 2011 at 12:30, Filip Maj <fil@adobe.com> wrote:
>
>> The reason I'm posting this is because we want to keep our plugin
>> interfaces aligned across platforms. It would be great if the other
>> platforms implemented this as well. Also would love to hear what the
>>rest
>> of the team thinks of this change.
>>
>
>I like the concept, but think perhaps the API could be changed a bit.
>
>Suggest that Plugins can implement a method Plugin::onMessage(String id,
>Object data) as suggested, which will be invoked when a message is
>"posted".  In addition, Plugins implement (via superclass) a method
>Plugin::postMessage(String id, Object data).  Looks like it's currently
>called onMessage() and implemented on PluginManager.  Why expose another
>class (PluginManager) when we can put this in the Plugin itself?  And why
>call an API that sends a message "onMessage".

Agree with this. Keep it to the Plugin interface and name it postMessage.

>We should agree on the synchroncity of postMessage() and onMessage()
>invocations and document them in the source comments.  Does postMessage()
>not return until all plugins are sent onMessage()?  Or are these
>asynchronous?  I think synchronous makes sense, and then we should
>document
>that onMessage() invocations are blocking the main thread, so shouldn't do
>long-running tasks.

Conceptually I think this is no different than making a call into plugins
from JS. I would lean towards async mechanics. Some plugins may need to do
long-running tasks when handling messages. This kind of reminds me of the
discussion we had initially about plugins, whether they are sync/async. We
quickly realized that async is the way to go. The project in incubation is
called callback, after all ;)

>Rather than send every event to every plugin, perhaps plugins should
>indicate that they wish to receive events.  Another API perhaps:
>Plugin::listenForMessages(boolean).  Don't listen, we won't send messages.
> Not sure it's worth it.

+1; set this to false as default and then plugin authors can change +
implement onMessage/postMessage when they need it.

>
>We should consider how the id's should be namespaced.
>
>We should be documenting for each plugin which id's they send and respond
>to.  Doesn't need to be in the user docs (obviously), but does need to be
>documented somewhere.  I guess code comments will be good enough for now.

Good enough for now, maybe something that should be discussed once we get
into plugin packaging.

>
>In terms of the naming of the APIs themselves, there may be some confusion
>as folks may confuse these names with ones available in the DOM (eg,
>https://developer.mozilla.org/en/DOM/window.postMessage ).  My only
>suggestion, which I'm not immediately happy with, is to stuff the string
>"Plugin" into the APIs: onPluginMessage() and postPluginMessage().  I
>dunno, maybe not so horrible.

A bit more verbose, not a big deal I think. Either way works IMO.

>
>-- 
>Patrick Mueller
>http://muellerware.org


Mime
View raw message