Taking quotes on building LC external for RethinkDB

Mark Waddingham mark at livecode.com
Sat Aug 5 21:58:31 EDT 2017


Hi Tom,

Nothing in my previous post was to do with your request - we will get back to you as quickly as we can with a quote for what you asked.

Whether that is a driver for revDB or a direct wrapper for the low-level C API raised to a suitable level of abstraction will depend on the analysis we do.

The functionality you need is the important thing here and not the manner or means.

Warmest Regards,

Mark.

Sent from my iPhone

> On 6 Aug 2017, at 01:42, Tom Glod via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> Hi Mark,
> 
> I don't really know what to make of that thread and I wouldn't pretend to
> understand everything thats being talked about here or there....so i'm jst
> thinking out loud.
> 
> I believe I might have mis-spoken by calling it a driver..... its really a
> LC external that acts as a driver.
> 
> 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.
> 
> It would be more perform ant to build this as an external and closer to the
> engine...as far as I know anyways..... unless thats completely wrong.
> 
> Here is the link again.......
> 
> https://www.rethinkdb.com/docs/writing-drivers/
> 
> Thanks for making me aware of the past efforts with RethinkDB.
> 
> On Sat, Aug 5, 2017 at 4:36 PM, Mark Waddingham via use-livecode <
> use-livecode at lists.runrev.com> wrote:
> 
>> Err - given that revDB is an *SQL* database wrapper and MongoDB is not an
>> SQL database you can imagine that creating an abstraction layer to deal
>> with both might be 'quite' hard - if not impossible.
>> 
>> So, given that we've now been open source for over four years and as such
>> that code has been open for others to contribute to for four years please
>> feel free to try and propose an API which works relatively seemlessly for
>> all types of databases that exist today - I'll happily review it and help
>> ensure it is worthwhile.
>> 
>> Less 'rants' and more actual intellectual effort please. This isn't down
>> to static and dynamic libraries, that is just the colour of the bikeshed at
>> this level - and trying to claim that anything related to that is the issue
>> here is just misleading people.
>> 
>> Warmest Regards,
>> 
>> Mark.
>> 
>> P.S. My point here is simply that whilst their may be an abstraction which
>> unifies all databases it sits so far up in the abstraction hierarchy that
>> trying to make revDB do it would be entirely pointless. The 'revDB' rewrite
>> you speak of has been subsumed by a number of db libraries which solve the
>> issue of low-level access that revDB provides. Whether that be dblib,
>> sqlyoga, or the way to abstract in a domain specific case as typified in
>> many apps (e.g. The photo app in the createit course) have provided.
>> Indeed, let's not pretend that the issue with supporting all kinds of
>> 'database' here is at the C / API level because it really isn't.
>> 
>> P.P.S. Abstractions are what makes things easy - abstracting too far and
>> all you end up doing is proving that 1 = 1 in numerous not particularly
>> interesting ways. What you might call "category theory 101".
>> 
>> Sent from my iPhone
>> 
>>> On 5 Aug 2017, at 19:39, Mark Wieder via use-livecode <
>> use-livecode at lists.runrev.com> wrote:
>>> 
>>>> On 08/04/2017 05:38 PM, Alex Tweedly via use-livecode wrote:
>>>> I have to admit that rethinkdb sounds really interesting - I hadn't
>> heard of it until your posting.
>>>> Might be worth a crowdfunding / donation request to spread the cost;
>> while I don't have a *need* for it, it might be a worthy target for (a
>> small amount) of my optional spending of my 'pocket money' ;-)
>>> 
>>> <rant>
>>> http://quality.livecode.com/show_bug.cgi?id=3662
>>> </rant>
>>> 
>>> <rant continued>
>>> In 2006 all existing database bugs in bugzilla were rolled into one
>> omnibus 'revDB review' bug report, and the individual report statuses were
>> all changed as 'resolved'. This in favor of 'We will shortly be reviewing
>> revDB' for a major rewrite of the database layer.
>>> 
>>> Had this actually been done anytime in the intervening eleven years,
>> adding new database types would be much easier. At some point I tried to
>> add mongodb to the engine and eventually hit a brick wall because of an
>> incompatibility with the existing library structure (a clash of static and
>> dynamic libraries, IIRC)
>>> 
>>> I realize revamping the database layer is a bigger task than trying to
>> shoehorn more database types into the existing bucket, but I think it's
>> high time to revisit (crowdfund) this. Otherwise we're just digging
>> ourselves deeper into the existing muck.
>>> </whatever>
>>> 
>>> --
>>> Mark Wieder
>>> ahsoftware at gmail.com
>>> 
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the use-livecode mailing list