TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Content-Type: text/plain; charset=us-ascii
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
From: David Botton <[log in to unmask]>
Date: Thu, 16 Sep 1999 10:10:23 -0700
MIME-Version: 1.0
X-To: Jacob Sparre Andersen <[log in to unmask]>
Parts/Attachments: text/plain (54 lines)
--- Jacob Sparre Andersen <[log in to unmask]> wrote:
> Maybe we are doing this the wrong way. What prevents
> us from
> implementing whatever services we want as a simple
> HTTP
> daemon?

For sure!

> Then we would just have to ask the user to
> launch
> the approppriate version of the daemon (OS
> dependent), which
> would bind to a local IP port (#1815?), where
> interactive
> links would point.

Or better yet just launch and Ada program that starts
the browser (in Win32 you can start the registered
browser easily IE or Netscape with a shell start api
call) and then generates then index file with a simple
meta tag that just refers back to itself with its
local IP port.

Example generated file:

<HTML>
<HEAD>
<meta HTTP-EQUIV="REFRESH" CONTENT="0;
URL=http://localhost:1234">
</HEAD>
<BODY></BODY></HTML>

Where 1234 is generated on the fly based on the port
it uses.

The entire httpd engine can just be a simple set of
packages that you register code with ala call back
style.

>
> We would even get the benefit of finding the URL of
> the
> files on the CD through the "referer" header.

Not needed if you integrate everything in to the Ada
program.

David Botton

__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

ATOM RSS1 RSS2