Closed
Bug 36297
Opened 24 years ago
Closed 24 years ago
Plugins Standard
Categories
(Core Graveyard :: Plug-ins, enhancement, P3)
Core Graveyard
Plug-ins
Tracking
(Not tracked)
VERIFIED
INVALID
People
(Reporter: netdragon, Assigned: serhunt)
References
()
Details
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•24 years ago
|
||
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.
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).
Reporter | ||
Comment 3•24 years ago
|
||
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•24 years ago
|
||
this is not a bug in mozilla. This is a topic for newsgroup discussion.
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 6•20 years ago
|
||
See article on http://developers.slashdot.org/article.pl?sid=04/06/30/1258204
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•