Re: Derived private interface

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

"Simon Wright" <simon@pushface.org> wrote in message 
news:m2sjpp4mar.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> 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.
>
> Interesting. I'd have thought that "implementing the server using OOP"
> and "not providing plugin facilities" were quite separate things. The
> OOP approach could, I suppose, be thought of as a way to provide you
> (Randy) with plugin facilities, but not attackers!

The root of the problem is that Ada 95 had no way to create a factory short 
of writing a giant case statement. That's annoying but OK if you have a 
complex interface with many operations to implement. However, the web server 
only has a single interface ("here's a URL and a socket, write the result to 
the socket"). So there is no advantage to having a separate case statement 
in the factory - that would just add complexity. (The output to the socket 
has many helper routines in order to make it easier to write the correct 
formats, but in any case the output is nearly free-form text and there is no 
obvious advantage to any extensions there.)

Even in Ada 2005 (which has somewhat better support for factories), you 
still have to "with" all of the units involved. It isn't much harder to 
write calls into a case statement (especially given the simplity of the 
interface).

The dynamic is different if the interface is more complex. For instance, the 
output modules of the ARM formatter program are based on an OOP-design 
(these output in various formats: RTF, HTML, plain text, etc.). For that, 
there is a case statement in the main program to select which output format 
is desired. But the interface has a significant number of routines to deal 
with output formatting, particularly of graphics and tables. Having to 
maintain 50 case statements would not be anywhere near as clean as the OOP 
design.

                                         Randy.