Re: Derived private interface

["Randy Brukardt" <randy@rrsoftware.com>]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:b0633538-6038-4167-860f-65ee9e7cddcc@k9g2000yqf.googlegroups.com...
On Jul 27, 1:43 am, Jeffrey Carter
<spam.jrcarter....@spam.not.acm.org> wrote:
...
>> for the significant improvement in ease of reading and
>> understanding that results.
>
>Did you try that with web servers?

Fasinating. While I agree with most of your points, it is interesting that 
the web server that runs the AdaIC archive site, the ada-auth.org site, the 
search engine for the RM, and RR Software's web site (which is an all-Ada 
design based on Claw's socket library) uses very little OOP. The only OOP in 
it is in the low-level socket operations, mainly because Claw sockets are an 
OOP design. But all of the high-level stuff is implemented as a table-driven 
approach (special handling, domain roots, and the like are all described in 
data form), and the specialty handlers (like the search engine) are all 
called from case statements driven from those data tables.

The design was driven by an extra-paranoid approach to security: if the 
server had any way for a URL to execute foreign code (a plug-in), then it is 
highly likely that an attacker would find a way to use buggy URL to execute 
some foreign code of their choice. Thus the ability to execute foreign code 
is not provided at all -- all handlers have to compiled into the web server. 
(Combined with Ada's near prevention of buffer overflows and stack attacks, 
the two most common vectors of the time were firmly plugged. Of course, 
traversal prevention and sanitization of parameters still have to be 
accomplished -- there is no silver bullet to security.) Once you've done 
that, there isn't much benefit to an OOP approach, since you have to 
enumerate all of the handlers somewhere in any case.

                                        Randy.