- From: Joe D Williams <joedwil@earthlink.net>
- Date: Wed, 27 Jan 2010 17:15:04 -0800
- To: "Joe D Williams" <joedwil@earthlink.net>, "Leonard Rosenthol" <lrosenth@adobe.com>, <julian.reschke@gmx.de>, "Adam Barth" <w3c@adambarth.com>
- Cc: "Maciej Stachowiak" <mjs@apple.com>, <public-html@w3.org>
I am trying to invent this from past and present experience, so I could use reference to some other words, maybe, but a plugin is: A plugin is a device that needs NAPI or something like it, or something like the IE activeX <object> interface. Or something entirely different? Maybe so but probably not. . NAPI, with all respect for great inventors, was initially designed for <embed>. The <embed> element was needed when there was the chance to implement another type of rendering context that required a runtime, like an audio, video, or early flash, for content encoded in ways and rendered in styles not built into the html browser. Not built-in meant things happened like when the binary for the <img src=''> might be displayed as text on the page before <img> was working good, except that the embedded media needed to be active and running at the same time as the host browser. It was complex enough to need its own runtime and internal event system but it was mostly trusted and was sequestered in a way that limited interaction with the early DOM. There are many details involved in getting this to happen. Anyway, the first plugins were simple and had some initializable features and <embed> evolved. Still, the main idea was to keep it as simple as possible, and as long as the runtime remained an isolated object, the host could keep track of whatever was necessary to support the actual functionality with relatively simple interfaces and thus restrict ways the plugin could affect its container. Then the HTML spec for this sort of thing was written and <object> appeared. This was intended as a true object-oriented interface tuned for maximum power in the 'plugin' along with maximum security for the execution context and its container. It allowed for initialization parameters to be sent to the 'plugin' at instantiation and for definition of runtime data and events to be negotiated between the host DOM and the plugin execution context. So for my point of view, this is important stuff. <object> remains as the most appropriate way to try and extend html in a decentralized way, except the <object> interface to the plugin has to be centralized. That is, in order to attract the most important extensions to html, html should have a nice complete definition of what it takes to be a full-fledged plugin running as an <object>. NAPI wants to be that standard. So, what is a plugin? A plugin uses an interface that is (like) NAPI and better.. A plugin is a separate context with limited interfaces to the host context. In my experience NAPI with <embed> was just too simple to give the interactions we really needed. Sure it is being updated, but still, I think it is basically for simple plugins with limited needs (even though as times move on, it may respond more like <object>). I sent this link out here before, http://www.hypermultimedia.com/ajax3d/index.htm The code of interest is shielded behind "AJAX" but this relatively simple set of examples may give a clue to what is a plugin. For this discussion, the important parts are how the host DOM communicates with the runtime represented by <object>. The notation SAI<=>DOM<=>XHR was used to present the idea that the SAI (The X3D plugin Scene Access Interface api) is talking to the host DOM (HTML/XML DOM api), and through the DOM to the XHR (network interface). For this discussion, the SAI<=>DOM interactions are most important. Once the thing is running (we need a nice set of interfaces that allow the author to use the host DOM to find out when it is actually running and live in the DOM for instance), interfaces to send events into the plugin context, and interfaces to allow the host DOM to listen for certain plugin events. From the inside, we need the interfaces that allow the plugin to exchange events and data with the DOM, and maybe more. There is more, for sure, I'm just talking about authoring. Following are two very general examples: 1. DOM=>SAI for propagating a click in the DOM into the SAI; DOM script gets access to <object> context DOM script changes <object> context. updates to object context get reflected in the object runtime. 2. SAI=>DOM for propagating a click in the SAI into the DOM DOM contains callback script(s) used to process event(s) from plugin SAI sends event when DOM should execute DOM callback script I think looking at SVG programming or any other type of plugin you will find similar concepts. For example, if an html browser wants to be a plugin (and it should want to be), all it has to do, as far as I know, is implement the plugin and browser parts of NAPI. Thanks Again and Best Regards, Joe
Received on Thursday, 28 January 2010 01:16:31 UTC