Re: Speaking of servers with API's...

Brian wrote: 
> So, I count at least 4 mentioned in this thread alone: Spyglass, NSAPI,
> Apache, Navisoft, and there is Microsoft's ISAPI.  Is there any interest
> in perhaps converging?  finding common ground?

I would encourage folks with an interest in converging to look at what we are 
making freely available:
  http://www.digicool.com/releases/

Using the ILU:
  ftp://ftp.parc.xerox.com/pub/ilu/
object interface system, everyone could agree to an ISL (like IDL) interface, 
and it would be portable across server products.  There would be some other 
benefits as well, such as access to remote objects, and the potential to speak 
a CORBA-type object protocol directly to the client.

The big benefit is the ability to do multiple languages to the API, 
particularly, scripting languages.  We are calling this "API scripting" to 
emphasize that you get the performance and features of using the API, with the 
simplicity and portability of CGI scripting.

Our company, along with several others participating, have done quite bit of 
work on this already:
1) Mapped to the Apache API and the Netsite API
2) Supported for Apache on Linux, Solaris, and Digital Unix, and for Netsite, 
on Solaris, Digital Unix and Window NT.  Others have it running on AIX and 
BSDI (for Apache).
3) Built a Python framework to make it very, very easy to write sophisticated 
applications

Some things to be done:
1) Map to more APIs (we are on the beta list for WebSite, are trying to get a 
Spyglass SDK, and might look at the ISAPI)
2) Finish preliminary work on a simple OLE bridge
3) Investigate embedding the ILU object inside of the httpd process
4) Look at threading ILU Python for better concurrency

We have used a version based on an ancient Apache since April.  We then moved 
to the Apache API, and Netsite.  Others have looked at it, and contributed 
patches, and are in active collaboration.

For performance, we have some very simple, preliminary numbers (read: I'm not 
standing by the methodology).  Basically, it is about 2.5 times as fast as CGI 
for similar problems, and w/in 5-10% the speed of getting an HTML file.  It 
appears that the performance looks better when you investigate throughput, 
versus latency.

We, and others, believe strongly that this is a viable alternative to the 
current CGI and API state of affairs.  Participation is open, so, if you are 
interested, let us know.

BTW, Brian, I guess we should get our module into the contrib area for Apache, 
eh?

--Paul

-- 
Paul Everitt       Digital Creations
paul@digicool.com  540.371.6909
"."

Received on Saturday, 27 January 1996 10:31:17 UTC