httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Ada95 problems with network data streams
Date Fri, 05 Sep 1997 14:21:04 GMT
Hi Sam,

It didn't occur to me that one of the GLADE folks might be listening
to the apache list.  I should have griped about it earlier.  ;-)
Keep in mind that I am not your typical Ada95 critic -- I've programmed
in over a dozen different languages, and am a Ph.D. student in a research
group that has been involved in Ada since strawman.  After years of
defending Ada, this experience has shocked and dismayed me.

I am putting together a libwww for Ada95, but it looks like we'll only
get a general network streams library done (that is streams as in
UnixSV STREAMS in user space, not Ada.Streams or C.Streams).
The primary problem with Ada95 is that it has none of the predefined
interface libraries found with Perl, Python, Java, and a host of other
modern languages.  I've been working for six months (half time) on this
project and we are almost to the point where I was with Perl4 after
two weeks.

One problem with Ada95 is that there is no systems interface for its
built-in types like String, Unbounded_String, Bounded_String, etc.
This means that whenever a built-in type needs to be "sent" outside an
Ada program, the program either needs to cheat (use the byte structure
of a private type as implemented by the given compiler) or copy the
data to a system type with a public structure (Storage_Array or char_array),
and then import a C routine to interface with the system.  Unfortunately,
there are no string-level operations (index, regex, ...) defined for
Storage_Array or char_array, so filters on a stream of data will end up
copying the array every time a character needs to be inserted or changed.
This is more of a problem with HTTP data streams than it is in Garlic
with RPC, since the latter uses fixed message sizes and blocking reads.

GNAT has an additional problem in that it does array copies one element
at a time instead of using something like memcpy(), but that isn't
really a criticism of Ada95.

Another problem I ran into this last weekend is that of creating a
class hierarchy of packages for streams.  The general streams class
has methods for manipulating a stream pipe (a sequence of interconnected
stream filter objects) which are the same for all streams, read and
write procedures for input_streams and output_streams, and more specific
procedures for TCP, File, Directory, and Filter stream objects.
I've tried three different variations on Ada95 OO derivation, but each
ran into a problem having to do with classwide type usage, being unable
to call an object-specific abstract routine within a classwide routine,
or some other aspect of Ada95's attempts to avoid multiple inheritance.
I'm going to try changing it to two separate (input/output) class
hierarchies today, which means code duplication, but the alternative
of implementing every method as stubs in the root class is worse.

I already have (or at least I think I have) workarounds for these problems,
so I don't really have a specific code problem to show you right now.
Since I need to dig through a 1000 page book whenever something that
should work is prevented by some obscure data typing rule, I am spending
way too much time on language-caused problems instead of the project.
I'll make the source freely available as soon as I can get enough of
the library working correctly.


View raw message