Taking quotes on building LC external for RethinkDB

[Richard Gaskin]

Yeah, I started to skim the security notes at
<https://www.rethinkdb.com/docs/security/>, but when I got to this:

    The best way to secure a RethinkDB cluster is to run it
    on a protected network that doesn’t allow access from the
    outside world. However, this may not always be feasible.
    For example, cloud deployments often require access from
    wide area networks.

    There are two main methods RethinkDB provides for securing
    the cluster: TLS encryption for connections, and binding
    the ports the server uses to specific IP addresses to limit
    outside connections.

...at that point I had to remind myself of other things demanding my 
attention. :) So tempting as it is, setting up a secure cluster is not 
something I'll be exploring soon.

Keep us posted. Interesting system....

-- 
  Richard Gaskin
  Fourth World Systems


Tom Glod wrote:

> to answer your question, the database cluster will be accepting connections
> and queries from clients directly.
>
> On Mon, Aug 7, 2017 at 11:51 AM, Tom Glod <tom at makeshyft.com> wrote:
>
>> Hi Richard .....  like Alex said, there is no Rest api for RethinkDB.  The
>> folks at RethinkDB didn't want to expose the whole query language using a
>> rest api, (if i recall correctly they said it is too powerful to do
>> so)...so the driver only accepts queries via driver port and streams
>> resulting json and updates back to client.
>>
>> My desktop client will connect to a local database which (will or can be
>> part) of a distributed cluster.
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Aug 7, 2017 at 10:53 AM, Bob Sneidar via use-livecode <
>> use-livecode at lists.runrev.com> wrote:
>>
>>> I was thinking the same thing. This isn't a database function per se,
>>> it's more like a sockets function.
>>>
>>> Bob S
>>>
>>>
>>> > On Aug 5, 2017, at 16:42 , Tom Glod via use-livecode <
>>> use-livecode at lists.runrev.com> wrote:
>>> >
>>> > If you go to this page ..... the specs say that it all happens through
>>> an
>>> > tcp/ip  connection where you make a connection, serialize the query and
>>> > send it ....  the db driver port receives queries, and streams data from
>>> > the db via the TCP/IP back to "subscribed" client.
>>> >
>>> > So it doesn't really need to have anything to do with the current
>>> > revdatabase functions....which the posts seem to be talking about.  I'm
>>> not
>>> > asking for a rewrite of db layer.