GREAT!!!!!!!! nowb if only I had something to write a plugin for, and an example to go by.

Anyone care making a simple example ?

Will Comunnitcator Plugins from 4.61 work when you upgrade to 5.0.

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.

-Ray ray@msgto.com

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: knollc@panasonic.com

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?

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).

-Chris

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.

-Chris

"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.

I think signing the applet would do what you want it to do. When you download a signed applet, I believe it is saved to your local system permemtly, and the class is put into your system classpath, so if I was to download a signed applet for quicktime, and the signed appliet was in a quicktime.jar file, and the package was com.applet.quicktime, ANY application or web site that wanted to use the com.applet.quicktime.QuicktimeApplet class, it would be found in my classpath. It would be a matter of simple javascript to determine if the applet was initialized, and if it wasn't it could open a new window to the signed applet download site.

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.

-Chris

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 ...

Mr. Anon,

What you could do is use the Netscape SmartUpdate feature to download and install signed JAR files. This is really slick in the fact that you can access the installed plugins registry to see if you have the correct version of your software installed on the client. If its not installed your JavaScript can check and then download an update based on registry settings. It's very nice, I've used it before in a previous project.

Vaughn