News and commentary from the cross-platform scripting community.
|
||
|
Mail Starting 11/28/97 | |
The *right* way to implement addons to IIS is Active Server Pages. CGI is obsolete.
From: eau@astsun.fujitsu.com.au (Eric Ulevik);
Sent at Mon, 1 Dec 1997 08:25:24 +1100;
CGI and IIS (not what you expect)I expect Netscape have a similar interface, but I have no experience with their servers.
The web master writes VBScript code in a web page that executes on the server, and calls your app. You should be able to execute in a separate EXE. For performance, we run everything in-process using DLLs.
To provide this facility, you need to implement Automation. The easiest way to do this is ATL (a class library that comes with VC5).
"Which web servers should we be concerned with?"
From: cskerr@geocities.com (Charles Kerr);
Sent at Sun, 30 Nov 1997 10:49:29 -0600;
Re:"Which web servers should we be concerned with?"http://www.netcraft.co.uk/Survey/ is a good site to find out which servers matter. Looks like Apache, Microsoft, and Netscape Enterprise support would bag you most of the servers. Right now Apache's got a 45% share, Microsoft has %19, and Netscape has %11... I thought Apache's share would shrink once Microsoft started bundling servers, but it's actually gone up slightly. And their new version will run on Windows, so who knows what will happen? Anyway, they're at http://www.apache.org/
Hi, Dave. My CGI experience is mainly with Mac and Unix servers, but I'm excited about Frontier CGIs on NT.
From: cahoon@oak.negia.net (Brad Cahoon);
Sent at Sun, 30 Nov 1997 09:43:00 -0500;
CGI scripting on WindowsEd Draper and others have commented that CGI is relatively low-performance, compared to the Netscape and Microsoft server APIs, but CGI is also well understood and widely used, and provides a basic level of compatibility between web servers.
If Frontier supports CGIs for one Windows web server, it can do the same for most others. The process would be similar to what people did to get Frontier's original CGI framework going with NetPresenz and Quid Pro Quo.
We're using Microsoft IIS on an internal server to run CGI-based groupware. We were running the Netscape server when I installed the groupware package, and nothing much broke when we switched to IIS. This low-tech quality seems like an advantage of CGI over the proprietary APIs.
The CGI/1.1 specification (http://hoohoo.ncsa.uiuc.edu/cgi/interface.html) describes how a web server and CGI script communicate through environment variables. This applies to Unix and NT web servers more directly than it does to MacOS servers, which use Apple Events to simulate environment variables.
Here's a gimmick that helped me understand CGIs on NT a little better: with the Netscape server, you can write a DOS batch file, put it in the cgi-bin directory, and call it from your browser with a URL like http://server.com/cgi-bin/test.bat. I don't know if IIS works the same way, but it would be consistent with the CGI specfication if it did. A simple how-to is at http://help.netscape.com/kb/server/960513-125.html.
The tricky part seems to be making CGI parameters available to Frontier (which could load them into an adrParams^ table as it does now on the Mac). Can Frontier can see NT environment variables?
I agree with those who are recommending that Frontier become an engine for the new Windows Scripting Host, which would probably solve this and many other problems. Here's a _LAN Times_ review of Windows Scripting Host that gives some sample code for working with environment variables: http://www.lantimes.com/lantimes/97/97oct/710b093a.html
On the subject of Apache: the latest beta, 1.3b3, runs under both NT and Windows95. When it becomes available as a binary, a lot of cool free software developed with Apache on Linux will also be available to NT users. This seems likely to change the Windows web server market. http://apache.org/docs/windows.html
My introduction to CGIs was with MacHTTP and Aretha around March 1995. I'm spending more time now working with Perl CGIs on Unix servers, but I'll continue to use MacOS web servers just because we're getting so much value from Frontier. I think the benefits of hooking Frontier to Windows web servers will be great.
Not to beat a dead horse, but I also agree with Ed Draper suggesting that you make Frontier a Windows Scripting Engine. The basically means that you'd need to implement an interface to Frontier which is a COM object. A basic scripting engine only requires two interfaces (about 16 functions total) beyond standard COM support.
From: poz@stellarsemi.com (Shannon Posniewski);
Sent at Fri, 28 Nov 1997 15:43:27 -0800;
Re:"Frontier as a COM Object"It isn't difficult to make COM objects, but there is a fairly long ramp up time in order to learn how it all works. Once you grok it, it makes sense. Until the "Aha!" moment, though, it can be rough.
I mentioned making Frontier COM-friendly previously when you posted your plans for calling DLLs from Frontier. Being a Windows Scripting Engine would be a great start in the direction of a COM-based Frontier. You could probably make the Engine COM part separate from Frontier itself and have it communicate through whatever back-end channels you devise, although I think the biggest bonus for Frontier on Windows will come when it eats, sleeps, and breathes COM.
Here is a useful link to the basics you need to do to make a WSE:
http://www.microsoft.com/msdn/sdk/inetsdk/help/compdev/engines/engines.htm#ch_script_engine
I have been lurking for the last several months and enjoying scripting.com.
From: lomas@bcu.ubc.ca;
Sent at Fri, 28 Nov 1997 14:18:52 -0800;
NT Server SupportI find that your switch to NT parallels mine and I am grateful for your windows-newbie mail list.
I would like to place an emphatic request for o'reilly website support for Frontier. We recently set up an NT Server Website and started off with IIS 3.0 (because everyone else was using this). We spent a frustrating 3 months trying to get Visual Basic and Perl CGIs to run under this platform, eventually coming to a compromise where we would run the CGIs on Website (port 81) called from IIS (port 80) [although our technical expertise had been limited to the mac prior to this].
We found Oreilly WS to be well documented, nicely set up with good integration of features that were useful to us. O'Reilly tech support seemed to be quick with answers to problems -even those that seemed to be primarily MS based (database stuff). Additionally, O'Reilly does seem to have a healthy attitude to 3rd party developers (see their partnerships with Allaire and iHTML) supporting very innovative products. I can't help but think that they would be very enthusiastic about your innovative product.
I can't be positive enough about O-Reilly. If you want more reasons, let me know and I can continue for pages. ; - ) Finally, I should finish up with the standard disclaimer-I am not associated with this company, just a very satisfied customer.
Just wanted to throw another vote of confidence behind Ed Draper's comments. I would love to add Frontier scripting to my ASP tool chest. I want to be able to extract data from relational databases, the file system, etc, and manipulate this data with Frontier scripts. Also, on most of our projects, we end up sticking all of our subroutines and functions in a universal server-side include file; I'd much rather store these things in the Frontier database and give all of our projects access to the thing.
From: derek@schwa.com (Derek Odegard);
Sent at Fri, 28 Nov 1997 15:43:51 -0600;
Frontier as COM objectApache is now available for NT, and I suspect that it could very well become as popular on NT as it is on Unix (where it is by far the most popular web server).
From: mast@interlog.com;
Sent at Fri, 28 Nov 1997 14:48:00 -0500 (EST);
web serversDave, the only universal way to do Windows CGIs is to use real CGIs rather than the direct API. The tradeoff is that CGIs get much less control and much less performance, much like the difference between ACGIs and WSAPI plug-ins on the Mac.
From: hopmann@holonet.net (Alex Hopmann);
Sent at Fri, 28 Nov 1997 12:12:47 -0800;
Win CGIsEd Draper was 100% on the mark- His suggestions are great and while they are a bit harder to pull off, they would make Frontier a full scale player in the Windows scripting environment, both for web site applications as well as for any other application that can take advantage of scripting.
Let me know if I can help with more info,
Not a definitive answer by any stretch...
From: dsmith@smartpatents.com (Dave W. Smith);
Sent at Fri, 28 Nov 1997 11:01:04 -0800;
Windows CGINetscape and Microsoft have different server APIs for "fast" CGIs.
There's a passibly good tutorial on Netscape CGIs buried on the Netscape FastTrack CD. It covers "ShellCGI" (i.e., command-line programs like Perl scripts), Java serverlets, and the NSAPI interface for DLLs. Shell CGIs run in separate processes, NSAPI CGI's run in separate threads (on NT, at least), and I'm not yet sure about Java serverlets.
I can't speak to Microsoft's with any authority.
I'd be really surprised if someone hasn't abstracted away the differences. A net search on "NSAPI ISAPI" should turn up some pointers.
I touched on this subject last week when I sent a message about Frontier and COM to the Frontier Work list. The are a number of different ways you can go in wiring Frontier into Windows web servers resulting in varying degrees of coolness. As far as which web server you should focus on, I'd say Microsoft's IIS. It's a great server and comes standard with NT Server.
From: draper@pacmedia.com (Ed Draper);
Sent at Fri, 28 Nov 1997 12:08:40 -0600;
Win CGIsWithout a doubt, the coolest thing UserLand could do with Frontier is to make it a Windows Scripting Host. Once it's a WSH, it's pretty much like a OSA language on the Mac. People can write Active Server Pages using Frontier (which would be GREAT!). Right now MS has WSHs for VB and JScript. A number of third parties are working on different languages such as Perl and Tcl.
You can find out more about WSH at:
http://www.microsoft.com/management/wsh.htm
The second coolest thing you can do is create a COM (ActiveX) interface to Frontier. Once you have an ActiveX interface, users can register Frontier as an ActiveX or OLE server object. Once it's registered, clients can instantiate it and work with it like any OLE or ActiveX server object.
The third coolest thing is to an ISAPI (IIS plug-in) which can call Frontier natively through its thread safe and high performance IIS in-process environment.
http://premium.microsoft.com/msdn/library/sdkdoc/isapimrg_1ecz.htm
The least coolest, but still very useful, thing would be to have an executable file which can call Frontier through a command line interface. This method is being discourage due to scalability problems on busy sites and the large performance hit that will be encountered every time a CGI is executed (NT must create an entirely new process).
Regarding DDE - I'd recommend staying away from it. It's dead technology that isn't being used much anymore. Microsoft moved away from it to OLE and from OLE to ActiveX and now from ActiveX to DNA. In other words, everything from, and including, OLE is COM based. COM is where you want to be on Windows.
http://www.cbooks.com/sqlnut/SP/search/gtsumt?source=&isbn=1572313498
I hope this helps.
