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."
#1 Help Sun and Mozilla with new 'Pluglet' API Spec
Wednesday August 4th, 1999 2:41 PM
GREAT!!!!!!!! nowb if only I had something to write a plugin for, and an example to go by.
Anyone care making a simple example ?
#2 Will Comunnitcator Plugins from 4.61 work
Wednesday August 4th, 1999 4:22 PM
Will Comunnitcator Plugins from 4.61 work when you upgrade to 5.0.
#3 Will Comunnitcator Plugins from 4.61 work
Wednesday August 4th, 1999 5:08 PM
Yes, the v4 plugins already work in Mozilla. Mozilla will have a beefier plugin ability though (Which isn't compatible with v4)
#4 Number ONE problem with V4 plugins
Thursday August 5th, 1999 1:35 AM
No alpha transparency capability. Problem is, plugin windows are always "in front" no matter what. If they are positioned in front or behind other day, they aren't allowed even 1-bit alpha capability.
With Java2D/Java, PNG, absolute positioning etc, plugins should somehow be able to support alpha canvases.
Plugins (atleast Java pluglets) need to be installable like ActiveX controls.
It would be really nice if whatever Java VM is shipped could be integrated with Mozilla's keystore, and support installing, registering properties and configuration information, and dealing with security policies.
This is the number one advantage ActiveX has which is the ability to ship signed plugins that autoinstall.
Um, Mr. Anon, you can have signed Applets that give you all the access to the local system resources (printers, com ports, hard disk) just like an ActiveX control, but in a cross platform way. And, as far as auto installing, what applet have you run across that hasn't auto installed?
My question about this whole topic is that isn't a Pluglet the same thing as an Applet? Can't an applet do the same thing as any plugin (such as display AVI files or MOV files like the quicktime plugin) merely by writing the rendering engine in java and making it an Applet? If the Pluglet/Applet needs access to system resources, just sign it.
Dazed and Confused.... -Chris: <firstname.lastname@example.org>
>And, as far as auto installing, > what applet have you run across > that hasn't auto installed?
Well, all of them actually. As soon as you quit the browser they're gone. Plugins are installed in the browser's directory so that you don't have to download them more than once. At least what I think the previous poster was referring to re: ActiveX. I sometimes wonder how the Netscpe/Marimba Netcaster (aka Castanet for Communicator) would have fared if there'd a good, fast JVM available for it to run on...
#10 Applets install temporary
Thursday August 5th, 1999 10:29 AM
>And, as far as auto installing, > what applet have you run across > that hasn't auto installed?
As stated above An applet must be reloaded every time you restart your sesion.
If Pluglets are going to be useful, they'll actually have to be two-tiered.
First, plain-jane applet mode, for the first time use. It probably should be signed, so that the actual applet can be pulled off of the Pluglet Manufacturers server, but still access the file on the content provider's server, (this allows for Manufacturers to insure the latest version of the software is being used, and possibly some download/usage tracking).
Second, an option on first time use to "install" the pluglet to a local directory is wanted. this way the Pluglet would load much quicker on susiquent uses. An option should be available to allow one time use as well, so users don't have to install a gazilion different pluglets for content types they tried once.
This also gives Pluglet designers the option to offer a pluglet-only mode for use in web-sites, and a standalone mode that could run independant of the browser for playing the content off of a local drive (assuming the user chose to install the pluglet locally).
#7 Pluglet v Applet
by pohl <email@example.com>
Thursday August 5th, 1999 8:33 AM
An Applet is limited to whatever fixed-size region is defined in the applet tag. Is this true for a pluglet? Could a pluglet handle a variable-size region? If so, does it get resize events? Could it even take over the entire viewable area, like integrated pdf viewers sometimes do?
a Pluglet is not an Applet, it is a Plugin written in JAVA
#18 Pluglets could be better than ActiveX
Sunday August 8th, 1999 9:24 AM
From what I got out of the spec is that pluglets are more flexible than ActiveX controls. ActiveX is a very flexible component system if your running Windoze. My company has been able to use ActiveX to Run a web browser interface to our web application server. Basically, with teh activex control, the application server can run locally off of teh CD-ROM without an internet connection. The control can query the database and generate responses in an HTML format. We can only to that with ActiveX at the moment. If we used plug-ins and teh lay out had frames, we would need a plugin to be loaded with each frame.
The Beatuty of the Pluglet spec ( from what I got so far) is that the pluglet can have complete control over the browser using the embeded application model. This model allows you to embed the mozilla browser into your app. The best part about all of this is that it is entirely cross-platform. Given Netscape great track record for cross-platform compatibility, I'm very ecited about this project. I hope this helps.
Those .class files don't cache because the browser doesn't allow it, but there's no reason why they can't be cached like any other file (like images). Also, if applets are placed in .jar files, they are cached on the local file system.
As far as making the applet display area resizable, there's NO reason why you shouldn't be able to set a width and height as percentages (much like tables) in the width and height of the applet parameter. It's just that previous browsers implementation didn't allow it, but Java does allow resizing of all panels, therefore the browser can resize an applet without problems (one way to do this is to have the applet open up a seperate frame).
I still don't understand how you get non autoinstall based on the fact that you need to download the class files every time you restart your browser. IT's just that the applet needs to autoinstall over and over again, but it IS all automatic, there's no user intervention (as opposed to 'manual' install where you need to take manual steps to install the software).
"install" implies that the code is placed on your HD permanantly.
The Applet model is similar to a "Network Install" available with certian Office productivity packages. The actual executible is available out on a network drive, and while you can run it off this drive, even pulling down certain portions of the code to your own local drive/memory, the next time you want to run it, you still have to go out and pull it down again. This takes up network resources, load time, and isn't always available to you (say the network goes down, or you have a notebook, that isn't always hooked into the network)
An "AutoInstall", at least to my mind (which is a tad feverish at times) implies that, once run it Automatically places the executables on your drive permenantly, so that the next time you run it, there's no need to pull anything from the network, or even to have network conectivity at all.
The Ideal pluglet autoinstall would actually permanently convert itself to native machine code so that the JVM wouldn't even be needed on further usages, but now I'm getting ahead of myself.
Yes, you're definitely getting ahead of yourself. A Java-to-Native compiler built into the browser is a bit much to expect. We don't even have *reliable* JVM's on all platforms yet.
It's not realy all that far fetched... the JVM already converts Java byte-code to native machine code anyways. its just a matter of saving the fully compiled bytecode after its been through the JIT (I expect its a tad more complicated than that, but that would be the gist of the "procedure"). I know, that goes contrary to what the JIT was created for, but taking one full compile hit to create a native plugin automatically isn't any worse than the procces we follow now with plugins for N4.x (in fact its a darned sight more pallatable)
I think the definition of autoinstall that has been defined by other posters: 'Permenantly copy files onto the local filesystem' is both a paradox, and not secure. Currently, if you are installing a plugin now, you have to at least tell all browsers to 'get the plugin' from a pop up window. Right there, it's not automatic. Also, if you are going to have any signed code to install software, again, you have to allow that software to be installed, and AGAIN, it's not automatic. The whole purpose of the java sandbox is that you can install software components without any user intervension, but in order to maintain the security of the sytstem, serious restrictions were placed on the java sandbox.
So, what you all are describing is persistant applets, which maybe could be as simple as adding a new parameter to the appliet tag such as persistant="true" or something like that wich informs the browser that it should hold on to the class files.
#17 More Than a Persistant Applet
Friday August 6th, 1999 8:34 AM
"you have to at least tell all browsers to 'get the plugin' from a pop up window. Right there, it's not automatic."
OK, point taken. But after the uproar about cookies being placed on your system with prior concent, no executable code would concievably be automatically installed without some form of validation from the end user.
lets, for the sake of argument, create some definitions.
"Manual Install" - any procedure that permenantly places executable code on the local drive, prior to allowing the end user to run it.
"Auto install" - any procedure that, after apropriate authorisation from the end user, permanently places executable code on the local drive after its initial execution from the network.
"Temporary Install" - any procedure that places executable code on the local drive after each execution, removing it once the program is complete. (I concede that, in the case of an applet, the code will actually be localized for the length of the browsers session, allowing subsiquent local executions during thiis period of time)
A setting of persistant="true" would, technically, be in acordance to my definition of Auto Install (assuming a pop-up verification dialog warns me that the code is being placed perminantly on my drive), but there is still the fact that the "perma-applet" also has to reside on the network end as well, and on every location where web-sites wish to use it. (i.e different servers, not different pages)
A pluglet should be different from an applet in two respects.
First, the browser should call the pluglet based on the type of content being delivered to the browser, not by the website that wants to show the content. An example of this is VRML. The web designer doesn't imbed the VRML plugin in the page, they imbed the .wrl file, and let the browser decide which plugin to run. If none is available, you are asked if you wish to install one.
Second, a pluglet might concievably be a standalone java application that runs seperately from the browser, as well as being "embedable" in the browser. Adobe's Acrobat .pdf viewer is a good example of this.
To be a seemless auto install, the browser would, apon finding a content type for which no plug-in resides locally, go off to a web based plugin "broker" to automatically pull down a signed pluglet. (perhaps giving the user a choice between various different pluglets, if more than one exists for the content type) At that time, the end user would be given the choice to run once (Temporary install) or permanantly install (auto install) while the pluglet is running.
My only point to this whole discussion is that a pluglet API may be unnessary when all the functionality could be done with signed applets. I think the Java API is getting a bit too large as it is, so we should actually try to work within the framework, not extend it every time we want to do something different.
#20 A Few Things Missing Still.
Monday August 9th, 1999 11:04 AM
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.
<<Many times, content is simply called from a link ...>>
This is it in a nutshell.
So one could add some cool features to the Editor like drag and drop widgets for adding form elements to a page so drop-down and scroll widgets could be right-clicked in the Editor to produce "inspector panels" where one could fill in some dialogs for adding queries to database backends etc.
Maybe composer and mail reader plugins too for mail sorting, interfaces for taking advantage of ezlm qmail maildir stuff etc.
If they are extensible there's no reason an Editor and mail/news reader couldn't be as good as Emacs/Gnus ...
#23 Pluglets vs. Applets - AutoInstall
by vbullard <firstname.lastname@example.org>
Tuesday April 24th, 2001 8:42 AM