The Third Manifesto ForumThe Third Manifesto: Tutorial DTutorial D as a service

Please or Register to create posts and topics.

Tutorial D as a service

#1 · June 24, 2019, 12:39 am

Quote from johnwcowan on June 24, 2019, 12:39 am
I've been thinking about what it would be like to have a web application with no back-end except a TD-enabled database. The idea is that the front-end ships a Tutorial D program to the database, which executes it and returns exactly what the front-end wants. This is inspired by reading the GraphQL spec, which defines a language (in the nature of query by example) that can be sent to a graph database to pull highly specific information out of it. My interest is in what extensions to Tutorial D would be needed to make such a thing feasible.

I think a statement like AUTHENTICATE subject AS identity, where subject and identity are string-valued expressions of the caller's identity and authentication information, would be a Good Thing. These would then be looked up in the database catalog to determine exactly which public relvars are accessible and what can be done with them. This statement would necessarily appear before any reference to public relvars, most likely at the top of the program.

I think the best approach to handling this would be to have two relvars in the catalog, SUBJECT of type {SUBJECT_NAME, AUTHENTICATION, ROLE_NAME} with {IDENTITY} as a key, and ROLE of type {ROLE_NAME, RELVAR_NAME, ACTION} with {ROLE} as a key, all strings. We then c0mputeSUBJECT JOIN ROLE, and if a tuple {SUBJECT_NAME, AUTHENTICATION, RELVAR_NAME, ACTION} exists in it, that means that if SUBJECTNAME and AUTHENTICATION are the expressions provided in the AUTHENTICATE statement, RELVAR_NAME is the name of a public relvar as a string, and ROLENAME is either "ACCESS" or "ASSIGN", then that authenticated subject can access or assign to (which implies accessing) the specified public relvar. Programs that try to use other public relvars are rejected. This is about the simplest possible RM specification of role-based access control.

Other scalar information needed by the TD program can be written into it using manifest constants such as CONST LOCALE = "en_US" or CONST TIMEZONE = "America/New_York", or (lacking such syntax) using scalar assignment statements.

Finally, we need to know what to return to the front end. A new statement RESULT expr AS "string", where "string"is some literal string, will do the job. The expression will be evaluated and returned using a format known to the implementation and specified by "string", such as CSV, JSON, Tutorial D code containing definitions of manifest relation constants or initialized private relvars, or what you will.

I've been thinking about what it would be like to have a web application with no back-end except a TD-enabled database. The idea is that the front-end ships a Tutorial D program to the database, which executes it and returns exactly what the front-end wants. This is inspired by reading the GraphQL spec, which defines a language (in the nature of query by example) that can be sent to a graph database to pull highly specific information out of it. My interest is in what extensions to Tutorial D would be needed to make such a thing feasible.

I think a statement like AUTHENTICATE subject AS identity, where subject and identity are string-valued expressions of the caller's identity and authentication information, would be a Good Thing. These would then be looked up in the database catalog to determine exactly which public relvars are accessible and what can be done with them. This statement would necessarily appear before any reference to public relvars, most likely at the top of the program.

I think the best approach to handling this would be to have two relvars in the catalog, SUBJECT of type {SUBJECT_NAME, AUTHENTICATION, ROLE_NAME} with {IDENTITY} as a key, and ROLE of type {ROLE_NAME, RELVAR_NAME, ACTION} with {ROLE} as a key, all strings. We then c0mputeSUBJECT JOIN ROLE, and if a tuple {SUBJECT_NAME, AUTHENTICATION, RELVAR_NAME, ACTION} exists in it, that means that if SUBJECTNAME and AUTHENTICATION are the expressions provided in the AUTHENTICATE statement, RELVAR_NAME is the name of a public relvar as a string, and ROLENAME is either "ACCESS" or "ASSIGN", then that authenticated subject can access or assign to (which implies accessing) the specified public relvar. Programs that try to use other public relvars are rejected. This is about the simplest possible RM specification of role-based access control.

Other scalar information needed by the TD program can be written into it using manifest constants such as CONST LOCALE = "en_US" or CONST TIMEZONE = "America/New_York", or (lacking such syntax) using scalar assignment statements.

Finally, we need to know what to return to the front end. A new statement RESULT expr AS "string", where "string"is some literal string, will do the job. The expression will be evaluated and returned using a format known to the implementation and specified by "string", such as CSV, JSON, Tutorial D code containing definitions of manifest relation constants or initialized private relvars, or what you will.

#2 · June 24, 2019, 4:24 am

There's quite a few websites offering various levels of 'try it out online' for a variety of languages. Anything from an interactive prompt in 'calculator mode' to source code entry REPL where you can declare stuff and import from standard libraries.

For SQL there SQL Fiddle front end to MySQL and for Relational Algebra there's Relax. (Opinions vary as to how much Relax is recognisable as RA vs being SQL in Sheep's clothing.)

I imagine supporting Tutorial D online will be nothing but pain: do you provide a sample database? do you allow people to update it? how long before it gets so smashed you have to rebuild it? Do you allow people to declare and populate their own relvars? who pays for the data hosting? etc. So pushing that to somebody else's problem sounds attractive.

But my experience with those 'try it online' sites: they seldom/never upgrade the compiler version, so you can't try new innovations, you can't even get bugs fixed. Several Haskell sites have bitrotted to the extent they're useless. OTOH if the sites are successful, they get bought out by some venture capitalist who only wants to 'leverage' eyeballs for advertising and/or more hosting services.

It's not that hard to install your own free Haskell/C/Java/etc compiler. I've even managed to compile a Haskell compiler from source, using Unix emulation on a Windows machine -- and I'm a bumbling incompetent. I got the impression it's not that hard to install Rel (although must admit I've never tried). I believe it comes with a sample S&P database.

What you describe sounds like as much trouble as installing Rel. Why would any tyre-kicking 'TTM curious' relationalist want to go to that bother?

#3 · June 24, 2019, 6:17 am

Quote from johnwcowan on June 24, 2019, 12:39 am

I've been thinking about what it would be like to have a web application with no back-end except a TD-enabled database. The idea is that the front-end ships a Tutorial D program to the database, which executes it and returns exactly what the front-end wants.

This is a Very Bad Idea. It might work if the language had been explicitly designed for this purpose, but TD has not.

You cannot predict or control what the program will try to do. Assume the worst.
You can protect the database by ordinary authentication, but TD has many other capabilities to guard against.
Compilation is relatively expensive, and TD is not designed to minimise that.

A redesigned subset TD might alleviate the pain, but why bother?

Finally, we need to know what to return to the front end. A new statement RESULT expr AS "string", where "string"is some literal string, will do the job. The expression will be evaluated and returned using a format known to the implementation and specified by "string", such as CSV, JSON, Tutorial D code containing definitions of manifest relation constants or initialized private relvars, or what you will.

Yes, it might well be reasonable to upload a program that is a single expression of type Relation, to be evaluated and returned as a JSON value. But it needs to be able to interact with the types and operators previously compiled and stored in the database. TD is the wrong choice, but feel free to define something better.

Andl - A New Database Language - andl.org

#4 · June 24, 2019, 8:05 am

Quote from Dave Voorhis on June 24, 2019, 8:05 am
Unless I've misunderstand what the OP has in mind, it would actually be relatively simple to get Rel running in a browser. The Java UI toolkit it's built on -- SWT (Standard Widget Toolkit) -- has a Web analogue called RWT (RAP Widget Toolkit, where RAP is Remote Application Toolkit -- see https://www.eclipse.org/rap/) that essentially allows you to take an existing Java desktop application written using SWT and with minimal code changes, turn it into a Web application using RAP/RWT.

I've sometimes considered doing this -- and have created an (unreleased) framework for handling user account creation and the like -- but haven't taken it forward because of the inevitable level of support that would be expected and the server infrastructure I would have to provide. When I think about what benefit it would be to the typical user -- who is usually a student or researcher -- I can't find much justification to produce a browser-based version. The existing desktop distribution runs on the three major desktop operating systems (Windows, MacOS, Linux) and is zero-install -- just download it to anywhere and double-click on the Rel executable -- and it provides a native desktop experience with unlimited (except by your system) number of databases and storage space, and it's yours to do with as you see fit.

Contrast this with a Web version, which would require explicit account and database creation and deliver the usual slightly-awkward second-rate desktop-in-a-browser experience, and your personal data is now on someone else's server. So, not as good as the desktop version. Maybe it would be worthwhile so you could access Tutorial D on your tablet or mobile phone, but... Why?

However, if the intention is to create a browser-based lightweight D for use in building browser-based applications, that could be a useful thing, but I'd be hard-pressed to justify using Tutorial D as its syntax.

Or, if the intention is to create a Javascript client library for Rel (or some other Tutorial D implementation) to run in a browser -- for use in building browser-based applications underpinned by a shared D instead of a shared SQL DBMS -- that might be worthwhile. I don't think that requires any extensions to Tutorial D, because all authorisation and user account handling can be done via catalog relvars.

Unless I've misunderstand what the OP has in mind, it would actually be relatively simple to get Rel running in a browser. The Java UI toolkit it's built on -- SWT (Standard Widget Toolkit) -- has a Web analogue called RWT (RAP Widget Toolkit, where RAP is Remote Application Toolkit -- see https://www.eclipse.org/rap/) that essentially allows you to take an existing Java desktop application written using SWT and with minimal code changes, turn it into a Web application using RAP/RWT.

I've sometimes considered doing this -- and have created an (unreleased) framework for handling user account creation and the like -- but haven't taken it forward because of the inevitable level of support that would be expected and the server infrastructure I would have to provide. When I think about what benefit it would be to the typical user -- who is usually a student or researcher -- I can't find much justification to produce a browser-based version. The existing desktop distribution runs on the three major desktop operating systems (Windows, MacOS, Linux) and is zero-install -- just download it to anywhere and double-click on the Rel executable -- and it provides a native desktop experience with unlimited (except by your system) number of databases and storage space, and it's yours to do with as you see fit.

Contrast this with a Web version, which would require explicit account and database creation and deliver the usual slightly-awkward second-rate desktop-in-a-browser experience, and your personal data is now on someone else's server. So, not as good as the desktop version. Maybe it would be worthwhile so you could access Tutorial D on your tablet or mobile phone, but... Why?

However, if the intention is to create a browser-based lightweight D for use in building browser-based applications, that could be a useful thing, but I'd be hard-pressed to justify using Tutorial D as its syntax.

Or, if the intention is to create a Javascript client library for Rel (or some other Tutorial D implementation) to run in a browser -- for use in building browser-based applications underpinned by a shared D instead of a shared SQL DBMS -- that might be worthwhile. I don't think that requires any extensions to Tutorial D, because all authorisation and user account handling can be done via catalog relvars.

I'm the forum administrator and lead developer of Rel. Email me at dave@armchair.mb.ca with the Subject 'TTM Forum'. Download Rel from https://reldb.org

#5 · June 24, 2019, 2:40 pm

Quote from johnwcowan on June 24, 2019, 2:40 pm

Quote from AntC on June 24, 2019, 4:24 am

There's quite a few websites offering various levels of 'try it out online' for a variety of languages.

Not what I was talking about at all. I am talking about ordinary commercial applications, which nowadays normally have a front end in JavaScript, a back end in some programming language, and a SQL database. It's possible for the front end to generate and transmit SQL directly, but due to various mismatches this is not normally done, and the front end sends something, often JSON, to the back end, which consults the database as needed using SQL and retransmits the results in JSON. All authentication and access control is normally done by the back end, with the SQL engine's own authentication bypassed, to the detriment of things like logging.

Tutorial D, being a much richer language than SQL, can be generated (possibly from a template) by the front end directly and sent to the TD engine directly. Authentication assures that although alternative front ends can be written, they can't get access to the data.

Quote from dandl on June 24, 2019, 6:17 am

This is a Very Bad Idea. It might work if the language had been explicitly designed for this purpose, but TD has not.

You cannot predict or control what the program will try to do. Assume the worst.

Part of the point of authentication is to keep out malicious programs. Of course you want to use HTTPS and otherwise protect the program in transit. One-time authentication might also be a good idea.

You can protect the database by ordinary authentication, but TD has many other capabilities to guard against.

Given that malicious programs are off the table (see above), all you need is a defense against programs written badly by your own people. Ordinary time-and-memory limits such as all server OSes provide should be sufficient to guard against infinite loops and such forms of resource overconsumption. Network overconsumption by malicious actors can be prevented by very ordinary external DDOS-prevention services. Public relvars are the only thing a Tutorial D program has access to outside itself.

An open question is whether the specified actions READ and UPDATE are granular enough. One might also need INSERT to permit adding tuples to a public relvar while being unable to assign it otherwise. It's also possible that write-without-read is needed.

Compilation is relatively expensive, and TD is not designed to minimise that.

Compilation speed is a matter of implementation strategy. C code files that gcc labors over for seconds or even minutes compiles with the Plan 9 C compiler so fast that the next shell prompt happens as soon as you hit ENTER. (Due to a chicken-and-egg problem I can't compile plan9-cc here on x86_64 Linux to test this, but I have some experience with Plan 9, as well as the Plan-9-style 6g compiler for Go.)

Yes, it might well be reasonable to upload a program that is a single expression of type Relation, to be evaluated and returned as a JSON value. But it needs to be able to interact with the types and operators previously compiled and stored in the database.

Of course. In this context the Tutorial D server is assumed to have direct access to its backing store. (By the way, a DATABASE "string" statement is also required if the engine can serve queries against more than one database, though still only one database per program.) But a Tutorial D program can't do anything a single expression can't do (except write to public relvars if the RBAC allows it). I wouldn't be opposed to a TD server being able to accept a JSON object with namessubject, authentication, database, and expression as a simple case and returning JSON.

Quote from Dave Voorhis on June 24, 2019, 8:05 am

Unless I've misunderstand what the OP has in mind, it would actually be relatively simple to get Rel running in a browser.

Again, not what I have in mind (but interesting).

Or, if the intention is to create a Javascript client library for Rel (or some other Tutorial D implementation) to run in a browser -- for use in building browser-based applications underpinned by a shared D instead of a shared SQL DBMS -- that might be worthwhile. I don't think that requires any extensions to Tutorial D, because all authorisation and user account handling can be done via catalog relvars.

Exactly! (That is, the client library runs in the browser.) But no client library is actually needed, any more than a back end program today requires a SQL library to speak to its SQL database. For TD, a general-purpose templating library that understands TD string escaping would be enough.

I don't see how the shared D service can avoid doing its own authentication, and it needs information about what the database is and what the result is to be, though, hence the syntax proposals above. Can you clarify?

I hope all this is clearer than my original posting.

Quote from AntC on June 24, 2019, 4:24 am

There's quite a few websites offering various levels of 'try it out online' for a variety of languages.

Not what I was talking about at all. I am talking about ordinary commercial applications, which nowadays normally have a front end in JavaScript, a back end in some programming language, and a SQL database. It's possible for the front end to generate and transmit SQL directly, but due to various mismatches this is not normally done, and the front end sends something, often JSON, to the back end, which consults the database as needed using SQL and retransmits the results in JSON. All authentication and access control is normally done by the back end, with the SQL engine's own authentication bypassed, to the detriment of things like logging.

Tutorial D, being a much richer language than SQL, can be generated (possibly from a template) by the front end directly and sent to the TD engine directly. Authentication assures that although alternative front ends can be written, they can't get access to the data.

Quote from dandl on June 24, 2019, 6:17 am

This is a Very Bad Idea. It might work if the language had been explicitly designed for this purpose, but TD has not.

You cannot predict or control what the program will try to do. Assume the worst.

Part of the point of authentication is to keep out malicious programs. Of course you want to use HTTPS and otherwise protect the program in transit. One-time authentication might also be a good idea.

You can protect the database by ordinary authentication, but TD has many other capabilities to guard against.

Given that malicious programs are off the table (see above), all you need is a defense against programs written badly by your own people. Ordinary time-and-memory limits such as all server OSes provide should be sufficient to guard against infinite loops and such forms of resource overconsumption. Network overconsumption by malicious actors can be prevented by very ordinary external DDOS-prevention services. Public relvars are the only thing a Tutorial D program has access to outside itself.

An open question is whether the specified actions READ and UPDATE are granular enough. One might also need INSERT to permit adding tuples to a public relvar while being unable to assign it otherwise. It's also possible that write-without-read is needed.

Compilation is relatively expensive, and TD is not designed to minimise that.

Compilation speed is a matter of implementation strategy. C code files that gcc labors over for seconds or even minutes compiles with the Plan 9 C compiler so fast that the next shell prompt happens as soon as you hit ENTER. (Due to a chicken-and-egg problem I can't compile plan9-cc here on x86_64 Linux to test this, but I have some experience with Plan 9, as well as the Plan-9-style 6g compiler for Go.)

Yes, it might well be reasonable to upload a program that is a single expression of type Relation, to be evaluated and returned as a JSON value. But it needs to be able to interact with the types and operators previously compiled and stored in the database.

Of course. In this context the Tutorial D server is assumed to have direct access to its backing store. (By the way, a DATABASE "string" statement is also required if the engine can serve queries against more than one database, though still only one database per program.) But a Tutorial D program can't do anything a single expression can't do (except write to public relvars if the RBAC allows it). I wouldn't be opposed to a TD server being able to accept a JSON object with namessubject, authentication, database, and expression as a simple case and returning JSON.

Quote from Dave Voorhis on June 24, 2019, 8:05 am

Unless I've misunderstand what the OP has in mind, it would actually be relatively simple to get Rel running in a browser.

Again, not what I have in mind (but interesting).

Or, if the intention is to create a Javascript client library for Rel (or some other Tutorial D implementation) to run in a browser -- for use in building browser-based applications underpinned by a shared D instead of a shared SQL DBMS -- that might be worthwhile. I don't think that requires any extensions to Tutorial D, because all authorisation and user account handling can be done via catalog relvars.

Exactly! (That is, the client library runs in the browser.) But no client library is actually needed, any more than a back end program today requires a SQL library to speak to its SQL database. For TD, a general-purpose templating library that understands TD string escaping would be enough.

I don't see how the shared D service can avoid doing its own authentication, and it needs information about what the database is and what the result is to be, though, hence the syntax proposals above. Can you clarify?

I hope all this is clearer than my original posting.

#6 · June 24, 2019, 3:12 pm

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

Quote from johnwcowan on June 24, 2019, 2:40 pm

Quote from AntC on June 24, 2019, 4:24 am

There's quite a few websites offering various levels of 'try it out online' for a variety of languages.

Not what I was talking about at all. I am talking about ordinary commercial applications, which nowadays normally have a front end in JavaScript, a back end in some programming language, and a SQL database. It's possible for the front end to generate and transmit SQL directly, but due to various mismatches this is not normally done, and the front end sends something, often JSON, to the back end, which consults the database as needed using SQL and retransmits the results in JSON. All authentication and access control is normally done by the back end, with the SQL engine's own authentication bypassed, to the detriment of things like logging.

Tutorial D, being a much richer language than SQL, can be generated (possibly from a template) by the front end directly and sent to the TD engine directly. Authentication assures that although alternative front ends can be written, they can't get access to the data.

SQL isn't normally generated by the -- I presume, Web-based -- front-end because it would be an open invitation to SQL injection. The same applies to Tutorial D and Tutorial D injection. Better to communicate with a RESTful (or SOAP, I guess, if you want to go old skool) service on the server side, and it generates the SQL or Tutorial D.

I wrote a client library in Java for Rel, which is used by the Rel UI (aka DBrowser) for accessing local and remote Rel DBMS servers and can be used by end-user applications. Duplicating its functionality for client-side (or middleware-side) languages other than Java would be straightforward, as the (text-based) protocol is simple. However, I do need to add the equivalent to prepared statements, to avoid Tutorial D injection.

Quote from johnwcowan on June 24, 2019, 2:40 pm

Quote from Dave Voorhis on June 24, 2019, 8:05 am

Unless I've misunderstand what the OP has in mind, it would actually be relatively simple to get Rel running in a browser.

Again, not what I have in mind (but interesting).

Or, if the intention is to create a Javascript client library for Rel (or some other Tutorial D implementation) to run in a browser -- for use in building browser-based applications underpinned by a shared D instead of a shared SQL DBMS -- that might be worthwhile. I don't think that requires any extensions to Tutorial D, because all authorisation and user account handling can be done via catalog relvars.

Exactly! (That is, the client library runs in the browser.) But no client library is actually needed, any more than a back end program today requires a SQL library to speak to its SQL database. For TD, a general-purpose templating library that understands TD string escaping would be enough.

I don't see how the shared D service can avoid doing its own authentication, and it needs information about what the database is and what the result is to be, though, hence the syntax proposals above. Can you clarify?

I hope all this is clearer than my original posting.

Currently, each running Rel DBMS server manages one database. If you want multiple databases, you launch multiple Rel DBMS instances and put each one on a different port. Obviously, that may change in the future, but for my current purposes it works well.

Rel doesn't currently support user accounts or privileges, but adding them is on my to do list. The facility will require no additional syntax; adding users will be done by adding tuples to the sys.Users relvar. Granting access to a relvar will be done by adding tuples to the sys.Privileges relvar, and so on.

Again, I have reservations about a Web-based browser client that generates Tutorial D and connects directly to a Rel DBMS. That would allow arbitrary Web users to write their own clients to send arbitrary Tutorial D directly to a publicly-exposed Rel DBMS.

Generally, publicly exposing any DBMS engine is a bad idea. It should only be accessible to designated administrative endpoints and servers running privileged middleware. The Web-based clients should connect to the middleware, thus ensuring that Tutorial D -- and DBMS connections in general -- can only be accepted from the servers running the middleware.

Quote from johnwcowan on June 24, 2019, 2:40 pm

Quote from AntC on June 24, 2019, 4:24 am

There's quite a few websites offering various levels of 'try it out online' for a variety of languages.

Not what I was talking about at all. I am talking about ordinary commercial applications, which nowadays normally have a front end in JavaScript, a back end in some programming language, and a SQL database. It's possible for the front end to generate and transmit SQL directly, but due to various mismatches this is not normally done, and the front end sends something, often JSON, to the back end, which consults the database as needed using SQL and retransmits the results in JSON. All authentication and access control is normally done by the back end, with the SQL engine's own authentication bypassed, to the detriment of things like logging.

Tutorial D, being a much richer language than SQL, can be generated (possibly from a template) by the front end directly and sent to the TD engine directly. Authentication assures that although alternative front ends can be written, they can't get access to the data.

SQL isn't normally generated by the -- I presume, Web-based -- front-end because it would be an open invitation to SQL injection. The same applies to Tutorial D and Tutorial D injection. Better to communicate with a RESTful (or SOAP, I guess, if you want to go old skool) service on the server side, and it generates the SQL or Tutorial D.

I wrote a client library in Java for Rel, which is used by the Rel UI (aka DBrowser) for accessing local and remote Rel DBMS servers and can be used by end-user applications. Duplicating its functionality for client-side (or middleware-side) languages other than Java would be straightforward, as the (text-based) protocol is simple. However, I do need to add the equivalent to prepared statements, to avoid Tutorial D injection.

Quote from johnwcowan on June 24, 2019, 2:40 pm

Quote from Dave Voorhis on June 24, 2019, 8:05 am

Unless I've misunderstand what the OP has in mind, it would actually be relatively simple to get Rel running in a browser.

Again, not what I have in mind (but interesting).

Or, if the intention is to create a Javascript client library for Rel (or some other Tutorial D implementation) to run in a browser -- for use in building browser-based applications underpinned by a shared D instead of a shared SQL DBMS -- that might be worthwhile. I don't think that requires any extensions to Tutorial D, because all authorisation and user account handling can be done via catalog relvars.

Exactly! (That is, the client library runs in the browser.) But no client library is actually needed, any more than a back end program today requires a SQL library to speak to its SQL database. For TD, a general-purpose templating library that understands TD string escaping would be enough.

I don't see how the shared D service can avoid doing its own authentication, and it needs information about what the database is and what the result is to be, though, hence the syntax proposals above. Can you clarify?

I hope all this is clearer than my original posting.

Currently, each running Rel DBMS server manages one database. If you want multiple databases, you launch multiple Rel DBMS instances and put each one on a different port. Obviously, that may change in the future, but for my current purposes it works well.

Rel doesn't currently support user accounts or privileges, but adding them is on my to do list. The facility will require no additional syntax; adding users will be done by adding tuples to the sys.Users relvar. Granting access to a relvar will be done by adding tuples to the sys.Privileges relvar, and so on.

Again, I have reservations about a Web-based browser client that generates Tutorial D and connects directly to a Rel DBMS. That would allow arbitrary Web users to write their own clients to send arbitrary Tutorial D directly to a publicly-exposed Rel DBMS.

Generally, publicly exposing any DBMS engine is a bad idea. It should only be accessible to designated administrative endpoints and servers running privileged middleware. The Web-based clients should connect to the middleware, thus ensuring that Tutorial D -- and DBMS connections in general -- can only be accepted from the servers running the middleware.

I'm the forum administrator and lead developer of Rel. Email me at dave@armchair.mb.ca with the Subject 'TTM Forum'. Download Rel from https://reldb.org

#7 · June 24, 2019, 4:33 pm

Quote from johnwcowan on June 24, 2019, 4:33 pm

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

SQL isn't normally generated by the -- I presume, Web-based -- front-end because it would be an open invitation to SQL injection. The same applies to Tutorial D and Tutorial D injection. Better to communicate with a RESTful (or SOAP, I guess, if you want to go old skool) service on the server side, and it generates the SQL or Tutorial D.Y

Agreed, if your client software is dumb enough not to use a templating library. But such a library doesn't have to know anything about TD, only which characters aren't acceptable in TD strings, if any, beyond ". (The spec is silent on this point and on how to escape such characters.) The onus for Little Bobby Tables attacks is firmly on front-end programmers; the back end and the database don't need to know anything about them, especially if the database doesn't just blindly obey any DROP TABLE command it gets from the back end (see below). Most databases are misconfigured, so they need this kind of external protection.

Currently, each running Rel DBMS server manages one database. If you want multiple databases, you launch multiple Rel DBMS instances and put each one on a different port. Obviously, that may change in the future, but for my current purposes it works well.

Good enough.

Rel doesn't currently support user accounts or privileges, but adding them is on my to do list. The facility will require no additional syntax; adding users will be done by adding tuples to the sys.Users relvar. Granting access to a relvar will be done by adding tuples to the sys.Privileges relvar, and so on.

Okay, but then how does one inform Rel which user is to execute a given program? This doesn't have to be in the program code, of course, it can be out of band, part of whatever format the program uses to talk to Rel, and perhaps that is better.

Again, I have reservations about a Web-based browser client that generates Tutorial D and connects directly to a Rel DBMS. That would allow arbitrary Web users to write their own clients to send arbitrary Tutorial D directly to a publicly-exposed RelDBMS.

But without proper authentication their arbitrary TD code can't do anything because it will be rejected right away. If you're worried, have the front end sign (and perhaps encrypt) either the program or the TCP stream with the user's private key, where the public key for all users is available to the DBMS, and the DBMS reject all programs with unknown signatures.

Generally, publicly exposing any DBMS engine is a bad idea. It should only be accessible to designated administrative endpoints and servers running privileged middleware. The Web-based clients should connect to the middleware, thus ensuring that Tutorial D -- and DBMS connections in general -- can only be accepted from the servers running the middleware.

I think it's only a bad idea because DBMS engines are a backwater when it comes to modern security, and what security they have is routinely bypassed. The MySQL database that $EMPLOYER uses is accessed using a single username, $EMPLOYER's own name, and the easily-guessed password is stored en clair in the back end's source code. Given that sort of laxity, you need a back end. With modern security practices, it's not necessary.

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

SQL isn't normally generated by the -- I presume, Web-based -- front-end because it would be an open invitation to SQL injection. The same applies to Tutorial D and Tutorial D injection. Better to communicate with a RESTful (or SOAP, I guess, if you want to go old skool) service on the server side, and it generates the SQL or Tutorial D.Y

Agreed, if your client software is dumb enough not to use a templating library. But such a library doesn't have to know anything about TD, only which characters aren't acceptable in TD strings, if any, beyond ". (The spec is silent on this point and on how to escape such characters.) The onus for Little Bobby Tables attacks is firmly on front-end programmers; the back end and the database don't need to know anything about them, especially if the database doesn't just blindly obey any DROP TABLE command it gets from the back end (see below). Most databases are misconfigured, so they need this kind of external protection.

Currently, each running Rel DBMS server manages one database. If you want multiple databases, you launch multiple Rel DBMS instances and put each one on a different port. Obviously, that may change in the future, but for my current purposes it works well.

Good enough.

Rel doesn't currently support user accounts or privileges, but adding them is on my to do list. The facility will require no additional syntax; adding users will be done by adding tuples to the sys.Users relvar. Granting access to a relvar will be done by adding tuples to the sys.Privileges relvar, and so on.

Okay, but then how does one inform Rel which user is to execute a given program? This doesn't have to be in the program code, of course, it can be out of band, part of whatever format the program uses to talk to Rel, and perhaps that is better.

Again, I have reservations about a Web-based browser client that generates Tutorial D and connects directly to a Rel DBMS. That would allow arbitrary Web users to write their own clients to send arbitrary Tutorial D directly to a publicly-exposed RelDBMS.

But without proper authentication their arbitrary TD code can't do anything because it will be rejected right away. If you're worried, have the front end sign (and perhaps encrypt) either the program or the TCP stream with the user's private key, where the public key for all users is available to the DBMS, and the DBMS reject all programs with unknown signatures.

Generally, publicly exposing any DBMS engine is a bad idea. It should only be accessible to designated administrative endpoints and servers running privileged middleware. The Web-based clients should connect to the middleware, thus ensuring that Tutorial D -- and DBMS connections in general -- can only be accepted from the servers running the middleware.

I think it's only a bad idea because DBMS engines are a backwater when it comes to modern security, and what security they have is routinely bypassed. The MySQL database that $EMPLOYER uses is accessed using a single username, $EMPLOYER's own name, and the easily-guessed password is stored en clair in the back end's source code. Given that sort of laxity, you need a back end. With modern security practices, it's not necessary.

#8 · June 24, 2019, 5:06 pm

Quote from Dave Voorhis on June 24, 2019, 5:06 pm

Quote from johnwcowan on June 24, 2019, 4:33 pm

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

SQL isn't normally generated by the -- I presume, Web-based -- front-end because it would be an open invitation to SQL injection. The same applies to Tutorial D and Tutorial D injection. Better to communicate with a RESTful (or SOAP, I guess, if you want to go old skool) service on the server side, and it generates the SQL or Tutorial D.

Agreed, if your client software is dumb enough not to use a templating library. But such a library doesn't have to know anything about TD, only which characters aren't acceptable in TD strings, if any, beyond ". (The spec is silent on this point and on how to escape such characters.) The onus for Little Bobby Tables attacks is firmly on front-end programmers; the back end and the database don't need to know anything about them, especially if the database doesn't just blindly obey any DROP TABLE command it gets from the back end (see below). Most databases are misconfigured, so they need this kind of external protection. [...]

Again, I have reservations about a Web-based browser client that generates Tutorial D and connects directly to a Rel DBMS. That would allow arbitrary Web users to write their own clients to send arbitrary Tutorial D directly to a publicly-exposed RelDBMS.

But without proper authentication their arbitrary TD code can't do anything because it will be rejected right away. If you're worried, have the front end sign (and perhaps encrypt) either the program or the TCP stream with the user's private key, where the public key for all users is available to the DBMS, and the DBMS reject all programs with unknown signatures.

Generally, publicly exposing any DBMS engine is a bad idea. It should only be accessible to designated administrative endpoints and servers running privileged middleware. The Web-based clients should connect to the middleware, thus ensuring that Tutorial D -- and DBMS connections in general -- can only be accepted from the servers running the middleware.

I think it's only a bad idea because DBMS engines are a backwater when it comes to modern security, and what security they have is routinely bypassed. The MySQL database that $EMPLOYER uses is accessed using a single username, $EMPLOYER's own name, and the easily-guessed password is stored en clair in the back end's source code. Given that sort of laxity, you need a back end. With modern security practices, it's not necessary.

The most significant problem is SQL injection, where a badly-written client-side program dynamically constructs SQL strings to incorporate user input.

A secondary problem is validated users reverse-engineering Web apps to send custom-made code. The users are notionally legitimate -- they're using the access credentials they've been given -- and their access to the DBMS is legitimate; what they're doing with it is the problem.

SQL injection continues to be a problem because of corporate development culture, where the most junior and inexperienced developers tend to work on a transient and time-critical suite of Web applications. Under typical pressures, such developers cut corners, make mistakes, or don't know any better.

By forcing front-end apps to communicate with a RESTful API, you eliminate the possibility of client-side SQL injection (and can keep using inexperienced developers); you get the benefit of being able to share the (hopefully relatively-stable) middleware API with multiple client-side applications; you assign the more experienced developers to the middleware layer so you avoid SQL (or other query language) injection in the middleware layer; and you wall off the DBMS from direct access to the wider Internet, which otherwise invites DDOS attacks, password guessing, encourages client-side DBMS credential-theft, and so on.

Anyway, embedding query language code in the front-end application doesn't provide any benefit in terms of application design, as good modularisation divides front-end operations from middle-layer from back-end anyway.

Quote from johnwcowan on June 24, 2019, 4:33 pm

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

Rel doesn't currently support user accounts or privileges, but adding them is on my to do list. The facility will require no additional syntax; adding users will be done by adding tuples to the sys.Users relvar. Granting access to a relvar will be done by adding tuples to the sys.Privileges relvar, and so on.

Okay, but then how does one inform Rel which user is to execute a given program? This doesn't have to be in the program code, of course, it can be out of band, part of whatever format the program uses to talk to Rel, and perhaps that is better.

Yes, part of the connection/communication protocol, not in-language.

Quote from johnwcowan on June 24, 2019, 4:33 pm

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

SQL isn't normally generated by the -- I presume, Web-based -- front-end because it would be an open invitation to SQL injection. The same applies to Tutorial D and Tutorial D injection. Better to communicate with a RESTful (or SOAP, I guess, if you want to go old skool) service on the server side, and it generates the SQL or Tutorial D.

Agreed, if your client software is dumb enough not to use a templating library. But such a library doesn't have to know anything about TD, only which characters aren't acceptable in TD strings, if any, beyond ". (The spec is silent on this point and on how to escape such characters.) The onus for Little Bobby Tables attacks is firmly on front-end programmers; the back end and the database don't need to know anything about them, especially if the database doesn't just blindly obey any DROP TABLE command it gets from the back end (see below). Most databases are misconfigured, so they need this kind of external protection. [...]

Again, I have reservations about a Web-based browser client that generates Tutorial D and connects directly to a Rel DBMS. That would allow arbitrary Web users to write their own clients to send arbitrary Tutorial D directly to a publicly-exposed RelDBMS.

But without proper authentication their arbitrary TD code can't do anything because it will be rejected right away. If you're worried, have the front end sign (and perhaps encrypt) either the program or the TCP stream with the user's private key, where the public key for all users is available to the DBMS, and the DBMS reject all programs with unknown signatures.

Generally, publicly exposing any DBMS engine is a bad idea. It should only be accessible to designated administrative endpoints and servers running privileged middleware. The Web-based clients should connect to the middleware, thus ensuring that Tutorial D -- and DBMS connections in general -- can only be accepted from the servers running the middleware.

I think it's only a bad idea because DBMS engines are a backwater when it comes to modern security, and what security they have is routinely bypassed. The MySQL database that $EMPLOYER uses is accessed using a single username, $EMPLOYER's own name, and the easily-guessed password is stored en clair in the back end's source code. Given that sort of laxity, you need a back end. With modern security practices, it's not necessary.

The most significant problem is SQL injection, where a badly-written client-side program dynamically constructs SQL strings to incorporate user input.

A secondary problem is validated users reverse-engineering Web apps to send custom-made code. The users are notionally legitimate -- they're using the access credentials they've been given -- and their access to the DBMS is legitimate; what they're doing with it is the problem.

SQL injection continues to be a problem because of corporate development culture, where the most junior and inexperienced developers tend to work on a transient and time-critical suite of Web applications. Under typical pressures, such developers cut corners, make mistakes, or don't know any better.

By forcing front-end apps to communicate with a RESTful API, you eliminate the possibility of client-side SQL injection (and can keep using inexperienced developers); you get the benefit of being able to share the (hopefully relatively-stable) middleware API with multiple client-side applications; you assign the more experienced developers to the middleware layer so you avoid SQL (or other query language) injection in the middleware layer; and you wall off the DBMS from direct access to the wider Internet, which otherwise invites DDOS attacks, password guessing, encourages client-side DBMS credential-theft, and so on.

Anyway, embedding query language code in the front-end application doesn't provide any benefit in terms of application design, as good modularisation divides front-end operations from middle-layer from back-end anyway.

Quote from johnwcowan on June 24, 2019, 4:33 pm

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

Rel doesn't currently support user accounts or privileges, but adding them is on my to do list. The facility will require no additional syntax; adding users will be done by adding tuples to the sys.Users relvar. Granting access to a relvar will be done by adding tuples to the sys.Privileges relvar, and so on.

Okay, but then how does one inform Rel which user is to execute a given program? This doesn't have to be in the program code, of course, it can be out of band, part of whatever format the program uses to talk to Rel, and perhaps that is better.

Yes, part of the connection/communication protocol, not in-language.

I'm the forum administrator and lead developer of Rel. Email me at dave@armchair.mb.ca with the Subject 'TTM Forum'. Download Rel from https://reldb.org

#9 · June 24, 2019, 7:34 pm

Quote from johnwcowan on June 24, 2019, 7:34 pm

Quote from Dave Voorhis on June 24, 2019, 5:06 pm

A secondary problem is validated users reverse-engineering Web apps to send custom-made code. The users are notionally legitimate -- they're using the access credentials they've been given -- and their access to the DBMS is legitimate; what they're doing with it is the problem.

Since the front end is inherently insecure, it should take no responsibility for access control. If a user can get something from the back end via the official JavaScript, they can also get it via their own hacked JavaScript, so you should be sure the user doesn't have access to data they should not have access to, to put it pleonastically.

(It's like the sign "UNAUTHORIZED ENTRANCE PROHIBITED", which when unpacked means "People who are not authorized to open this door are not authorized to open this door.")

SQL injection continues to be a problem because of corporate development culture, where the most junior and inexperienced developers tend to work on a transient and time-critical suite of Web applications. Under typical pressures, such developers cut corners, make mistakes, or don't know any better.

No disagreement there.

By forcing front-end apps to communicate with a RESTful API, you eliminate the possibility of client-side SQL injection (and can keep using inexperienced developers); you get the benefit of being able to share the (hopefully relatively-stable) middleware API with multiple client-side applications; you assign the more experienced developers to the middleware layer so you avoid SQL (or other query language) injection in the middleware layer;

Well, my experience differs. I find that the back end changes far more than the front end, since there is far more business logic in it, and that inexperienced developers are just as likely to be used for the middleware, as front-end and back-end developers are not interchangeable (so-called "full stack" developers are normally either 90% BE and 10% FE or the reverse).

and you wall off the DBMS from direct access to the wider Internet, which otherwise invites DDOS attacks, password guessing, encourages client-side DBMS credential-theft, and so on.

All those things are just as possible with the exposed BE endpoints.

Anyway, embedding query language code in the front-end application doesn't provide any benefit in terms of application design, as good modularisation divides front-end operations from middle-layer from back-end anyway.

But this FE-BE-DB layering was not handed down from Mount Olympus. It was created in response to certain technical and social circumstances, and when those change it may become unnecessary. I think that adopting TD databases is just such a change. An existing example is

Quote from Dave Voorhis on June 24, 2019, 5:06 pm

A secondary problem is validated users reverse-engineering Web apps to send custom-made code. The users are notionally legitimate -- they're using the access credentials they've been given -- and their access to the DBMS is legitimate; what they're doing with it is the problem.

Since the front end is inherently insecure, it should take no responsibility for access control. If a user can get something from the back end via the official JavaScript, they can also get it via their own hacked JavaScript, so you should be sure the user doesn't have access to data they should not have access to, to put it pleonastically.

(It's like the sign "UNAUTHORIZED ENTRANCE PROHIBITED", which when unpacked means "People who are not authorized to open this door are not authorized to open this door.")

SQL injection continues to be a problem because of corporate development culture, where the most junior and inexperienced developers tend to work on a transient and time-critical suite of Web applications. Under typical pressures, such developers cut corners, make mistakes, or don't know any better.

No disagreement there.

By forcing front-end apps to communicate with a RESTful API, you eliminate the possibility of client-side SQL injection (and can keep using inexperienced developers); you get the benefit of being able to share the (hopefully relatively-stable) middleware API with multiple client-side applications; you assign the more experienced developers to the middleware layer so you avoid SQL (or other query language) injection in the middleware layer;

Well, my experience differs. I find that the back end changes far more than the front end, since there is far more business logic in it, and that inexperienced developers are just as likely to be used for the middleware, as front-end and back-end developers are not interchangeable (so-called "full stack" developers are normally either 90% BE and 10% FE or the reverse).

and you wall off the DBMS from direct access to the wider Internet, which otherwise invites DDOS attacks, password guessing, encourages client-side DBMS credential-theft, and so on.

All those things are just as possible with the exposed BE endpoints.

Anyway, embedding query language code in the front-end application doesn't provide any benefit in terms of application design, as good modularisation divides front-end operations from middle-layer from back-end anyway.

But this FE-BE-DB layering was not handed down from Mount Olympus. It was created in response to certain technical and social circumstances, and when those change it may become unnecessary. I think that adopting TD databases is just such a change. An existing example is

#10 · June 24, 2019, 8:27 pm

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

Quote from johnwcowan on June 24, 2019, 7:34 pm

Quote from Dave Voorhis on June 24, 2019, 5:06 pm

A secondary problem is validated users reverse-engineering Web apps to send custom-made code. The users are notionally legitimate -- they're using the access credentials they've been given -- and their access to the DBMS is legitimate; what they're doing with it is the problem.

Since the front end is inherently insecure, it should take no responsibility for access control. If a user can get something from the back end via the official JavaScript, they can also get it via their own hacked JavaScript, so you should be sure the user doesn't have access to data they should not have access to, to put it pleonastically.

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.

So, you withdraw all direct access to relvars and authorise only a stored-procedure/operator -only access to the database, which implements more restrictive rules than just privilege-based security. Inevitably, it looks like exactly the same remote procedure call -like interface that you would have provided in a RESTful middleware interface.

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. Indeed, last year I had a student explore that as a dissertation project to automatically expose stored procedures in MySQL as a Web service, which worked fairly well as a prototype. That would avoid the manual effort in creating a (RESTful or otherwise) middleware layer.

I think David Bennett's ANDL did this too, if I recall correctly.

Quote from johnwcowan on June 24, 2019, 7:34 pm

Quote from Dave Voorhis on June 24, 2019, 5:06 pm

By forcing front-end apps to communicate with a RESTful API, you eliminate the possibility of client-side SQL injection (and can keep using inexperienced developers); you get the benefit of being able to share the (hopefully relatively-stable) middleware API with multiple client-side applications; you assign the more experienced developers to the middleware layer so you avoid SQL (or other query language) injection in the middleware layer;

Well, my experience differs. I find that the back end changes far more than the front end, since there is far more business logic in it, and that inexperienced developers are just as likely to be used for the middleware, as front-end and back-end developers are not interchangeable (so-called "full stack" developers are normally either 90% BE and 10% FE or the reverse).

This demonstrates that, as is so often the case, different places and domains are different.

Ideally, all permutations of experience need be technically accommodated with greatest overall safety, so I'd argue that exposing the DBMS directly to the outside world (unavoidable if the browser can see it) is riskier -- if for no other reason that it's exposed directly to the vast unwashed -- than exposing it only to the middleware layer.

However, if the DBMS generates the middleware layer, that may be different.

Quote from johnwcowan on June 24, 2019, 7:34 pm

Quote from Dave Voorhis on June 24, 2019, 5:06 pm

and you wall off the DBMS from direct access to the wider Internet, which otherwise invites DDOS attacks, password guessing, encourages client-side DBMS credential-theft, and so on.

All those things are just as possible with the exposed BE endpoints.

Yes, but it's generally technically easier to detect and mitigate malicious access -- and limit damage when credentials are obtained -- for a Web service than for a classic SQL DBMS.

Though for something like Rel, it would be entirely feasible to implement intrusion detection and the like in the DBMS access layer, and -- as suggested above -- have the DBMS provide the Web service automagically generated from appropriately defined operators.

Quote from johnwcowan on June 24, 2019, 7:34 pm

Anyway, embedding query language code in the front-end application doesn't provide any benefit in terms of application design, as good modularisation divides front-end operations from middle-layer from back-end anyway.

But this FE-BE-DB layering was not handed down from Mount Olympus. It was created in response to certain technical and social circumstances, and when those change it may become unnecessary. I think that adopting TD databases is just such a change. An existing example is

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, but as suggested above, I think it preferable that it not be Tutorial D or any other D that is directly exposed to the front-end. Better, I think, that it be an already-familiar Web-service interface.

However, if that Web service can be generated and run automatically by the D DBMS -- whether it's Tutorial D or something else doesn't really matter, as long as it's appealing enough to woo developers away from the usual SQL choices -- then it might be a contender, particularly if it significantly reduces time/effort/cost/errors in developing (and running) the middle layer.

Quote from johnwcowan on June 24, 2019, 7:34 pm

Quote from Dave Voorhis on June 24, 2019, 5:06 pm

A secondary problem is validated users reverse-engineering Web apps to send custom-made code. The users are notionally legitimate -- they're using the access credentials they've been given -- and their access to the DBMS is legitimate; what they're doing with it is the problem.

Since the front end is inherently insecure, it should take no responsibility for access control. If a user can get something from the back end via the official JavaScript, they can also get it via their own hacked JavaScript, so you should be sure the user doesn't have access to data they should not have access to, to put it pleonastically.

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.

So, you withdraw all direct access to relvars and authorise only a stored-procedure/operator -only access to the database, which implements more restrictive rules than just privilege-based security. Inevitably, it looks like exactly the same remote procedure call -like interface that you would have provided in a RESTful middleware interface.

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. Indeed, last year I had a student explore that as a dissertation project to automatically expose stored procedures in MySQL as a Web service, which worked fairly well as a prototype. That would avoid the manual effort in creating a (RESTful or otherwise) middleware layer.

I think David Bennett's ANDL did this too, if I recall correctly.

Quote from johnwcowan on June 24, 2019, 7:34 pm

Quote from Dave Voorhis on June 24, 2019, 5:06 pm

By forcing front-end apps to communicate with a RESTful API, you eliminate the possibility of client-side SQL injection (and can keep using inexperienced developers); you get the benefit of being able to share the (hopefully relatively-stable) middleware API with multiple client-side applications; you assign the more experienced developers to the middleware layer so you avoid SQL (or other query language) injection in the middleware layer;

Well, my experience differs. I find that the back end changes far more than the front end, since there is far more business logic in it, and that inexperienced developers are just as likely to be used for the middleware, as front-end and back-end developers are not interchangeable (so-called "full stack" developers are normally either 90% BE and 10% FE or the reverse).

This demonstrates that, as is so often the case, different places and domains are different.

Ideally, all permutations of experience need be technically accommodated with greatest overall safety, so I'd argue that exposing the DBMS directly to the outside world (unavoidable if the browser can see it) is riskier -- if for no other reason that it's exposed directly to the vast unwashed -- than exposing it only to the middleware layer.

However, if the DBMS generates the middleware layer, that may be different.

Quote from johnwcowan on June 24, 2019, 7:34 pm

Quote from Dave Voorhis on June 24, 2019, 5:06 pm

and you wall off the DBMS from direct access to the wider Internet, which otherwise invites DDOS attacks, password guessing, encourages client-side DBMS credential-theft, and so on.

All those things are just as possible with the exposed BE endpoints.

Yes, but it's generally technically easier to detect and mitigate malicious access -- and limit damage when credentials are obtained -- for a Web service than for a classic SQL DBMS.

Though for something like Rel, it would be entirely feasible to implement intrusion detection and the like in the DBMS access layer, and -- as suggested above -- have the DBMS provide the Web service automagically generated from appropriately defined operators.

Quote from johnwcowan on June 24, 2019, 7:34 pm

Anyway, embedding query language code in the front-end application doesn't provide any benefit in terms of application design, as good modularisation divides front-end operations from middle-layer from back-end anyway.

But this FE-BE-DB layering was not handed down from Mount Olympus. It was created in response to certain technical and social circumstances, and when those change it may become unnecessary. I think that adopting TD databases is just such a change. An existing example is

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, but as suggested above, I think it preferable that it not be Tutorial D or any other D that is directly exposed to the front-end. Better, I think, that it be an already-familiar Web-service interface.

However, if that Web service can be generated and run automatically by the D DBMS -- whether it's Tutorial D or something else doesn't really matter, as long as it's appealing enough to woo developers away from the usual SQL choices -- then it might be a contender, particularly if it significantly reduces time/effort/cost/errors in developing (and running) the middle layer.

I'm the forum administrator and lead developer of Rel. Email me at dave@armchair.mb.ca with the Subject 'TTM Forum'. Download Rel from https://reldb.org

The Forum for Discussion about The Third Manifesto and Related Matters

Tutorial D as a service