On 11-11-16 1:47 PM, "Patrick Mueller" <[email protected]> wrote:
>On Thu, Nov 10, 2011 at 12:30, Filip Maj <[email protected]> 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
