36297 - Plugins Standard

Status: VERIFIED INVALID

(Core Graveyard :: Plug-ins, enhancement, P3)

Description

[Brian 'netdragon' Bober]

I was told a while ago to say this by itself(it is currently said in less detail 
in another bug of mine), and I didn't find a matching bug in Query. A problem 
with plugins on Comm. 4.x I noticed that some plugins had different protocols 
than others. For instance, the Quicktime plugin had different embed properties 
than Liveaudio, and when it overwrote it, some web pages didn't work. Different 
protocols for plugins that play the same file type require sniffing the plugin 
to determine what should be done. I think there should be a base set of embed 
properties and javascript commands for common file types such as MID, MP3, MPG, 
WAV that might have multiple plugins to choose from. For instance, a WAV player 
plugin should always have javascript commands to start, stop, get current 
location, pause, make a playlist, loop music, play for X amount of time, and 
start at a certain location, among others. Then, a plugin software can add its 
non-standard commands to the list. Of course, for plugins that do such things as 
show .pdf files, there is no need because there is only one plugin. Although 
there is a standard for HTML, there is no standard that I know of for plugins, 
and there should be. If the plugins are forced to be a certain way for NS 
browsers, then I do not see why they will not do exactly the same thing in 
Microsoft Browsers - so this will cause a standard to exist for both browsers. 
(Maybe my logic is flawed, though).

Comment 1

[David Hallowell]

I think I know what you're getting at here but the problem is you can't make
someone write their plugin to comply with any standards for performance.

Perhaps Netscape could write a guide to what makes a good plugin but that's
about all they can do with it.

This'll probably be marked invalid as this has nothing to do with bugs in
Mozilla. I'll leave it for another person to decide on the resolution of this
bug though.

Comment 2

[Adam]

The programmer's mantra: if you didn't write it, break it! (or is that just 
Microsoft's?). It's a good idea but nobody's going to comply (unless the Mozilla 
team adds code so that plugins not conforming to their standards don't work - but 
then plugin authors won't even bother writing Netscape versions).

Comment 3

[Brian 'netdragon' Bober]

I don't know much about how plugins work. Is there a way that you could include 
extern references to functions in the header files of the plugin SDK that are 
functions that must be included in the plugin. That way, the plugin won't 
compile if the function isn't included. For instance, a sound  
plugin would have to include a header file that has extern functions to start, 
stop, get current location, pause, make a playlist, loop music, play for X 
amount of time, and start at a certain location, among others. Maybe you could 
even place these external reference in object files so it couldn't be commented 
out. Then you could say in your guide that if for some reason, this function 
doesn't apply to a certain plugin, it would just do nothing and return NULL. 
Maybe there could be mime-specific extern functions, also. If this was possible, 
then people writing javascript code could always call a specific function 
independent of what plugin is controlling sound.

Comment 4

[Asa Dotzler [:asa]]

this is not a bug in mozilla. This is a topic for newsgroup discussion.

Comment 5

[Blake Ross]

vrfy invalid

Comment 6

[Brian 'netdragon' Bober]

See article on http://developers.slashdot.org/article.pl?sid=04/06/30/1258204