Licensing Engine for Commercial Applets - was IE Plugin: Congrats To Carl and Staff (and some requests/proposals/suggestions)

Hi Volker. I think that three arguments that can be made in favor of implementing the applet licensing code in the rebol.dll plug-in. 1. Avoiding Bandwidth Waste Due to Code Duplication 2. Applet Plug-in Platform Independence 3. Simplified Development/Maintenance (Less Errors) Thanks To Standard HTML call interface to REBOL: 1. Wasted Bandwidth Due to Code Duplication Let's say that the code needed to a) check if there is an up-to-date version of the rebol.dll (up-to-date relative to the requirements of the applet plugin); b) download a current version of the rebol.dll plug-in if applet plug-in cannot find rebol.dll or if the version that was found on the consumer's machine is not up-to-date; c) check the certificate of the applet plugin; d) load the rebol.dll or display a "pirate" alert; e) activate the loaded rebol.dll and pass it an entry-point to the applet plug-in f) plus all the additional code necessary to have Internet Explorer install the applet plug-in totals no more than 30KB (binary code) (probably a little more ....). Then each and every applet plug-in will have to extra carry this code with it. Let's say a Web site consists of ten pages that include some applet plug-in (catalog, shopping cart, member registration, live support, live salesperson, feedback, order entry, order status checking, animations, etc.). So, we're looking at a total of 300KB additional footprint. 300KB is certainly not a catastrophe, but it's not a good starting point. Now, let's assume the Web site is fairly busy and generates an average of 1000 visits a day that make use of all ten Web pages. So, now the 300KB total overhead * 1000 users translates into 300MB of extra bandwidth required per day, or a little over 9 GB of bandwidth wasted per month. Putting all the necessary code into the REBOL plug-in instead of the applet plug-in avoids this wasted 9GB bandwidth. 2. Applet Plug-in Platform Independence Applet Plug-ins should not be dlls: Imagine if you have to create, test, and debug three different versions of your applets, for each expected consumer platform, Windows, Linux, or OS/X (what about Solaris, AIX, HPUX, Amiga/OS, Elate?) because your applet plug-in as a Windows dll will not run under Linux, etc. If, however, the rebol.dll (or an equivalent rebol embeddable for Linux, OS/X, etc.) are used to encapsulate all that stuff, then the applet plug-in can be a platform independent plug-in with platform support provided transparently by the platform-specific rebol plug-in that is executing your code. The Web browser loads the platform specific rebol executable, and the rebol executabe then loads one and the same platform-independent 3rd party applet. 3. Simplified Development/Maintenance (Less Errors) Thanks To Standard HTML call interface to REBOL: By delegating the authentication to REBOL we also gain the advantage of a single, uniform call interface when we use the rebol.dll, whether rebol.dll is used execute some source code, or some protected, commerial binary code. While the programmer is testing his code, he will be asking to the Web browser to call the rebol.dll with a REBOL source file argument, as for instance, the REBOL example panel on rebol.net <OBJECT ID="RPluginIE" CLASSID="CLSID:ADDAB378-54F2-4D4E-ABBB-E164FC772AAA" CODEBASE="http://www.rebol.com/downloads/plugin/rebolplugin.cab#Version=0,0,0,2" WIDTH="360" HEIGHT="414"> <PARAM NAME="LaunchURL" value="http://www.rebol.net/plugin/tests/test.r"> </OBJECT> He'll have an easier time switching between source code and compiled version of his applet, if he only needs to change the PARAM value filename suffix, instead of having to change the whole OBJECT call sequence. You wrote:

>Would do that the other way around. make the rebol.dll loadable from your dll. >that way certificates-checker knows its your dll and certificate, not RT's >dll and certificate. >