I think people are overlooking some other bigger competitors
in the web world, one which we can partially incorporate
and another that we could totally incorporate. These
are Java and its vast collection of web capabilities
(from all the url stream connections, to html rendoring, etc)
 - which JGNAT will help with,
and the other is XML - which is starting to be big
in communicating between web entities (servers or clients)
and using https or http to get through firewalls, etc. (see
http://www.xml.org)

  At present, there are no full XML/DOM parsers written in
Ada (that I know of). There are some "C" ones, and lots
of Java ones. Also the http://java.apache.org site is looking
at these issues of open-source.  This situation makes Ada programmers
at a very distinct disadvantage in XML and therefore Web
programming. Sure this will be available when using JGNAT
but not for native users of Ada - and most equilivent
code in Java won't be embedded as applets.

  Also, no internet projects that I know of that handle
high speed, high demand issues are dealing with CGI at all.

A couple good resources to check out:

"XML and Java"
    http://pws.prserv.net/Hiroshi.Maruyama/xmlbook/
and the
"XML Specification Guide"
    http://www.utoronto.ca/ian/books/xmlbook/index.html

XML and DOM would be great projects if people are looking at
new uses of Ada. Even providing a portable Ada binding to
the "C" parsers would help.

-scott

ps.
I wrote up some of these Ada/Internet issues
in a paper this past fall:
   http://WhiteRiverRanch.com/papers/adafrance99.pdf

Tom Moran wrote:
>
>   A situation in which an embedded system communicates to public
> outside systems via HTTP & HTML would seem a logical candidate
> for an embedded, custom, server.  It might call internal
> routines instead of using the CGI mechanism, for instance.
> It might be reasonable to skip support of some HTTP things,
> in which case, as has been demonstrated, it could be quite
> small and easy to create.  It could be carefully vetted,
> which might be rather more tedious with a full-up COTS server.
>   I find it more difficult to imagine scenarios where a
> custom browser of limited capability would be as worthwhile.