Help Sun and Mozilla with new 'Pluglet' API Spec
Tuesday August 3rd, 1999
Akhil Arora of Sun writes,
"Help define the Pluglet API
A Pluglet is a Plugin that is written in Java. A draft of the Pluglet API specification has been posted here. We would like Plugin writers to get involved in defining the API. Does it meet your needs? What additional feature would you like added to it? What pet peeve of yours would you like fixed? Please talkback at the netscape.public.mozilla.java newsgroup [at news.mozilla.org] or the email@example.com mailing list."
#20 A Few Things Missing Still.
Monday August 9th, 1999 11:04 AM
You are replying to this message
Yes, for 80% of what you want a plug-in to do, an Applet would probably be fine. Especially if the signed applets do deposit themselves into the browsers standard classpath. (i'm not 100% pecent on that either)
I still see those instances I mentioned as times where a pluglet could be preferable.
Applets can't be automatically called based soley on content. You would always be required to use the <APPLET> or <OBJECT> tag and arcitecure, which requires naming a specific applet/class/plug-in instead of the easier to implement <EMBED> tag, which can simply pass information about content. This may not seem like much, but in certain cases (VRML specifically) there may be several possible "viewers" for the content being embeded. By using the <OBJECT> or <APPLET> tags, the web-site designer is effectively forcing the end user to use the specific Applet/Plug-in they've named in their HTML to view the content, regardless of what the end user may already have installed on their system.
Also, applets must be embeded within a page (or container) to be used. Many times, content is simply called from a link, to be executed either with a seperate application, or in the entire viewable area of the browser. Neither of these options are possible with an applet.
Thirdly, in certain cases, the content being displayed is actually scatered throughout the regular HTML, and not religated to a specific area within the page. While I can't think of any specific Netscape Plugins that do this, I know that ActiveX's currently are capable of this. Specifically, Bitstream's TrueDoc ActiveX that is used as a sort of Page Re-Processor of sorts; going through the HTML document, and scanning all references to font faces, or families, and comparing them to previously defined <LINK type="fontdef">'s to determine whether or not to use an embedable font.