Re: Derived private interface

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 01 Aug 2011 11:30:33 +0200, Alex R. Mosteo wrote:

> Simon Wright wrote:
> 
>> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> 
>>> "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).
>> 
>> In my EWS (https://sourceforge.net/projects/embed-web-srvr/) there are
>> two 'classes' of response, Static and Dynamic. For static responses, the
>> page to be returned is fixed, and is baked in at build time. For dynamic
>> responses, I have a function
>> 
>>    type Creator
>>       is access function (From_Request : HTTP.Request_P)
>>                          return Dynamic_Response'Class;
>> 
>> and a means of registering Creators
>> 
>>    procedure Register (The_Creator : Creator; For_The_URL : HTTP.URL);
>> 
>> ('URL' isn't quite right, it's the 'abs_path [ "?" query ]' part of an
>> HTTP URL, eg /embed-web-srvr/ in the URL above).
>> 
>> For_The_URL is really a String, and the result of registration is
>> effectively a run-time factory. But no case statements!
> 
> I have done basically the same for my component-based robotic library, but 
> still you have to /with/ all the units you want and call the register 
> procedure...

You have not. The procedure Register is called from the body of the package
that provides an implementation. It adds an entry into the global map id ->
object constructor. The object factory sees only this map, it need not to
with any implementations. This is the way I implement persistency layers.

BTW, Generic_Dispatching_Constructor of Ada 2005 did not change much to Ada
95 because of tags. You still need a registering layer to maintain external
name to tag mapping.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de