incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Mueller <>
Subject Re: Change to Plugins introduced in Android
Date Wed, 16 Nov 2011 21:47:26 GMT
On Thu, Nov 10, 2011 at 12:30, Filip Maj <> 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".

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.

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.

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.

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, ).  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.

Patrick Mueller

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message