TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Tom Moran <[log in to unmask]>
Wed, 1 Dec 1999 21:49:30 +0000
Scott Moody <[log in to unmask]>
text/plain; charset=us-ascii
Scott Moody <[log in to unmask]>
text/plain (55 lines)
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

  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 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"
and the
"XML Specification Guide"

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.


I wrote up some of these Ada/Internet issues
in a paper this past fall:

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.