Daniel Stenberg wrote:
> On Wed, 21 Jan 2009, Tim Tassonis wrote:
>
>>> So no, to me it doesn't make much sense.
>>
>> Well, in my opinion it makes as much sense as the ldap stuff, which is
>> also a database access protocol. Which of course opens up the question
>> how much sense the ldap stuff makes.....
>
> I can only agree. If someone would come suggesting LDAP today I'd say
> the same things about that. And for DICT too I think.
>
> LDAP also suffers from being a rather "bad boy" in libcurl in that it
> has its own transfer-loop and doesn't work fine with the multi interface
> etc. But LDAP at least has a URL syntax already defined.
>
> Still, I'm interested in hearing reasons and arguments why ODBC is a
> good idea. Not how other protocols might also be bad... I'm prepared to
> turn around and change my mind if I get good and proper arguments why I
> am wrong.
>

Well, basically scriptability comes to my mind. I've often been in the
situation where I had to query a database from script and then process
it further. (employee address data, for instance). unixODBC does brings
a command line utility, but being more comfortable with curl, I would
prefer it.

As for programmability (libcurl), there is of course the odbc API, but
it definitely is one of the most horrible API's you can find, it's from
Microsoft after all (I already have written an own wrapper API, just so
my code looks saner and more compact).

So, for easy database queries, curl could provide its well-known and
clean interface to the tasks.

The one downside you already mentioned: the missing standard URL syntax.

My proposed syntax
odbc://user:pass_at_dsn/table?columns?conditions?sorting

seems logical and consistent to the existing URL syntaxes (at least to
me...) and suitable for simple queries, but of course it isn't a standard.

The even bigger question is the format of the output of a query, as curl
will always return one file and there is no such thing as a standard
relational database query output format. The possible ones that come to
my mind:

CSV
+ Easy to write, easy to read
+ Well known
- No standard regarding escaping/quoting of delimiters/special characters

XML
+ Buzzword compliant
+ Standardized
- Bigger Overhead

LDIF
+ Already used in curl
- Difficult to parse
- Not really intended for relational databases

I'm personally 50:50 about it, but would certainly provide help/code for
it when you would like to add support for odbc in curl.

Bye
Tim
Received on 2009-01-22