From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,158ce2376534c35d X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.78.MISMATCH!feeder.news-service.com!feeder.news-service.com!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Derived private interface Date: Mon, 1 Aug 2011 12:12:32 +0200 Organization: cbb software GmbH Message-ID: <1rlxo1uthv5xt.1agapd9q0mek4$.dlg@40tude.net> References: <27656578-65aa-48b9-9f89-4ebd4e0cb02a@glegroupsg2000goo.googlegroups.com> <0fe3b0f8-c064-444d-899d-640e891b58c3@w4g2000yqm.googlegroups.com> <128d8eb5-1cc6-47e3-a09b-b53a5ef289ce@m10g2000yqd.googlegroups.com> <4e141501$0$6629$9b4e6d93@newsspool2.arcor-online.net> <4b2728fc-6127-45d8-a314-9fc491701c26@g12g2000yqd.googlegroups.com> <82vcve4bqx.fsf@stephe-leake.org> <4e15b223$0$6541$9b4e6d93@newsspool4.arcor-online.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: QcbescVjKKy2/zkAIc0MRg.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: g2news1.google.com comp.lang.ada:20438 Date: 2011-08-01T12:12:32+02:00 List-Id: On Mon, 01 Aug 2011 11:30:33 +0200, Alex R. Mosteo wrote: > Simon Wright wrote: > >> "Randy Brukardt" writes: >> >>> "Simon Wright" wrote in message >>> news:m2sjpp4mar.fsf@pushface.org... >>>> "Randy Brukardt" 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