Re: What defines a "plugin"? WRT sandboxing?

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