The Forum for Discussion about The Third Manifesto and Related Matters

You need to log in to create posts and topics.

Tutorial D as a service

12
Quote from Dave Voorhis on June 24, 2019, 8:27 pm

You can certainly restrict access to only the relvars/tables/whatever meant to be readable and updatable by the client, but then the malicious outsider discovers that it's possible to flood-insert to some table/relvar because the client allows inserting one row/tuple under some circumstances. Or, discovers that a table/relvar can be emptied, because the client allowed a row/tuple to be deleted.

Excellent points both.  Updating does indeed need more complex access control than just "this relvar can/cannot be assigned", and perhaps the best way to do that is through middleware.

But I can see value in being able to expose selected stored procedures (or operators, in TTM parlance) automatically via an automatically-generated RESTful (or similar) interface, or even one provided by the DBMS itself.

The latter idea sounds great.

The three layer approach has a benefit that the middle layer can be shared by multiple front-end applications and monetised by selling access to third parties. You can do the same with DBMS access,

Indeed, this is already being done.  Some customers will pay extra to get (presumably read-only) access to monetized SQL databases.  See "Never Say No to Direct Database Access" and it's not uncommon in hosted solutions as well.

DuroDBMS includes a server (implemented using libmicrohttpd) which accepts HTTP requests of the form GET http://host[:port]/database/query

where database is the name of a database and query is a Tutorial D query, returning a result in JSON format. The result does not include a heading.

 

12