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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e8edf581e3a868a1 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!proxad.net!newsfeed.stueberl.de!uucp.gnuu.de!newsfeed.arcor.de!news.arcor.de!not-for-mail Message-ID: <41EAD62B.1040708@user1.uni-duisburg.de> Date: Sun, 16 Jan 2005 22:01:31 +0100 From: Georg Bauhaus User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: [ANN] Data Source Name parser (ODBC etc.) References: <41E7682D.8040306@futureapps.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Organization: Arcor NNTP-Posting-Date: 16 Jan 2005 22:01:43 MET NNTP-Posting-Host: dd8a3b5f.newsread4.arcor-online.net X-Trace: DXC=l:L^lohGF4ia0B5i45NL;d:ejgIfPPlddjW\KbG]kaMhFYk:AnJB[CmMhkG>7<\lf`:n9G[MMWD:dSGg0Q1RJSJb X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:7853 Date: 2005-01-16T22:01:43+01:00 List-Id: Nick Roberts wrote: > Georg Bauhaus wrote: > >> http://home.arcor.de/bauhaus/Ada/dsn.html >>... >>I have tried to make the interface simple, any comments as to whether it >>is usable or whether it should go down the drain will affect following >>versions. > I like the idea. I think the syntax you propose is great (it needs to be > completed). I'd like the query syntax to be defined and parsed, using the > familiar field=value form and & for conjunction. Thanks for the close examination! There are two reasons why the query string syntax is not (yet) present in the grammar (apart from lazyness, third reason). The first reason is that I wasn't sure it is the way to go. Are we indepentent of pre-existing ways to communicate additional information to database drivers? (I think we are, but I am not sure.) Second, parsers for query strings do already exist (in CGI packages), so I thought you just pick your favourite query string parser and pass the query string part of the DSN to that parser. Or should the DSN packages incorporate one of the offerings? > I like the good error diagnostics, but I feel the Messages interface is too > elaborate. Surely an enumerated type is not required, but just a message > string? The Messages interface is a bit elaborate, the reason was "compiler checked internationalization". I want a compiler to check the completeness of the set of error messages in some chosen natural language. This also leaves Messages' client packages untouched when messages are changed. I've done this before, it works nicely. (This technique also allows you to automaticalls produce a plain text file from the Messages package, or any file format that a translator prefers. :-) The Messages package eventuall becomes a unit that just renames a package of message constants in some national language, during software configuration. Another raison d'etre of the enumerated type of error messages is that you can use its values much in like you can use SQL error numbers. Also it's probalby easier to react to specific errors specified by number than specified by string values (in several national languages ;-). > And surely instantiating a generic is too elaborate, as well? Given your suggestion of separating the production of a parse results object from the production of a diagnosis object in case of syntax errors, I see that the generic/callback solution can be replaced. Though in this case we'll parse twice. Perhaps using error rules only the second time? I'll try. > Surely > only one derivation needs to be returned (if there is a legal derivation)? I have no proof yet, but right, it's almost sure that, absent error rules, the grammar isn't ambigous or erroneous at the level of detail given in the DSN spec. > type Data_Source_Descriptor is private; I like this type name better than my Data_Source_Details. If no one has any objections to using Data_Source_Descriptor instead, I'll raplace it. > Syntax_Error: exception; Hm. Yes if we use the two-subprograms approach. > The function Parse either successfully parses the given DSN (in Name) and > returns a broken down composite value (type Data_Source_Descriptor), or it > raises the exception Syntax_Error. > Source: constant Data_Source_Descriptor := Parse(...); A small design issue: Should the broken down Data_Source_Descriptor composite be allocated at the client side, that is, in code under the control of the library user? Or should the parse function create one? Similarly for the Diagnose function (which also needs to somehow know the capacity). > I'm interested in participating in the development of some kind of open > Database I/O interface package. Will http://gnade.sourceforge.net/ do? -- Georg