Re: Bridging GProlog with other systems [Was: Re: FFI experimentation, some advice please...]

[emacstheviking]

Ciprian,

Good mail. My first "real target" once I get FFI working is "cURL"... apart from MySQL, most if the new kids on the block these days have an HTTP(S) REST API making them easy to talk to, as usual the devil will be in the details. I mentally want to be able to do something like this:

   http_req(get, 'url', [ param(K,V), param(K,V), ... ], Response).

That's my personal way forward with what I have done so far and if it is in C or Prolog I don't really care so long as it works well and is "sensible" and "doesn't suck". I personally love the way that gplc allows me to add in plug-ins and then use the final binary just like the original gprolog (although --consult is brokne?!?!!?, did I fail to read docs well?) but with new shiny predicates preloaded and ready to rock and roll.

    Moreover, in response to the original poster idea of using MySQL,
Redis, etc. directly from GProlog, I think it's highly impractical
decision, especially since all development must be done in C (or
wrapping C++ in C code).  (Is there any "production-ready" RabbitMQ
library for C?  How about for Riak, CouchDB or many other "NoSQL"
solutions?)

I wouldn't say highly impractical, just the need to be methodical and meticoulous to get a core FFI system in place like Lisp or Haskell.

I have already used "librabbitmq" and "libmysqlcppcon" from C/C++ code and I know that they work well... as I said, if gprolog can speak FFI and/or cURL then we are away! I have also used Redis, Riak, CouchDB and may other REST driven tools during my day job in the last few years, a lot with Erlang and a lot with PHP. I have evaluated MQZero too but we didn't use it and went for a clustered RabbitMQ solution.

I will check out your stuff over the weekend to see what I may have missed as well in terms of ideas for solutions.

For me though, I kind of like the idea of minimal moving parts and being able to  produce the smallest piece of kit that just works is what drives me. The more technologies you mix the more failure points you have and then it snowballs as you wrap measures around each failure point etc etc I am sure we have all been there and seen it happen; what was a small simple working system now looks hideous.

I never discount anything though so I will def. read those github resources, being a hacker junky! I had a quick look for ten minutes and that is some pretty sexy code that is.

All the best chaps, have a good weekend...

:)
Sean

On 5 July 2013 13:40, Ciprian Dorin Craciun <address@hidden> wrote:

On Fri, Jul 5, 2013 at 1:56 AM, Sean Charles <address@hidden> wrote:
> I am already having delusions of grandeur and thinking about using RabbitMQ,
> Redis and MySQL and writing non-deterministic code that returns each row of
> a result set or keeps reading from an AMQP queue just because I can. For my
> day job, the ability to showcase Prolog would be great but it has to connect
> to all the usual stuff to be seen to be useful.


    A little bit off topic from the original subject of FFI, however
related with "bridging" GProlog with other "modern" systems.

    Indeed GProlog can be a perfect "secret" weapon behind a lot of
solutions, especially since it's simple and small enough to use and
extend, and it's compilable to machine code (thus no distribution
headaches).  However making it "talk" with today's software is a
daunting task (at a first glance).  I know there are "raw" sockets and
the usual "text" or "binary" consuming "functions", however this means
going to back to the basics on both sides (GProlog and the component
sitting at the other end).
    Moreover, in response to the original poster idea of using MySQL,
Redis, etc. directly from GProlog, I think it's highly impractical
decision, especially since all development must be done in C (or
wrapping C++ in C code).  (Is there any "production-ready" RabbitMQ
library for C?  How about for Riak, CouchDB or many other "NoSQL"
solutions?)

    Moreover, in response to the original poster idea of using MySQL,
Redis, etc. directly from GProlog, I think it's highly impractical
decision, especially since all development must be done in C (or
wrapping C++ in C code).  (Is there any "production-ready" RabbitMQ
library for C?  How about for Riak, CouchDB or many other "NoSQL"
solutions?)


    However I think one could easily do the following instead:

    * implement an "efficient" (i.e. in C) JSON parser and formatter
that reads properly formatted UTF-8 JSON and spits out Prolog terms
(terms with some constraints), plus the reverse transformation;
    * implement a "gateway" to the outer world based on ZeroMQ;  (both
"client" mode to allow "asking" questions, i.e. REQ sockets, and
"server" mode to allow "receiving" questions, i.e. "REP" sockets;)
    * then, implement an adapter (or "driver") based on the same
technologies (ZeroMQ and JSON) that translates these requests towards
the wrapped resource;  (for example NodeJS, Go or even Java would be
perfect candidates for such a task;)


    Completing these (especially the first two), means GProlog is now
able to "communicate" with the rest of the "modern" world.  :)
Overhead and security is not such a big issue, since ZeroMQ can be
made to talk over UNIX domain sockets, or even "in-memory" if the
other end of the communication channel runs as a separate thread in
the GProlog process, thus not "mangled" with the GProlog VM.


    If someone is interested of such a direction I have a prototype
that solves the JSON part (by using the Jackson library), and the
ZeroMQ "server" part.  It's open source (LGPL3) and on GitHub at the
link below.  To test (or at least see the "look-and-feel" of the
solution) see the files in `sources/tests`:  in a couple of lines it
bridges a Python client with a GProlog server.  To build you require
Ninja (also linked below): just type `ninja` and see the `.outputs`
folder.

      https://github.com/cipriancraciun/volution-gprolog-libraries
      https://github.com/martine/ninja

    (My intention was to use GProlog for describing and enforcing
ACL's in a NodeJS web-service.  A "binding" to LevelDB or Memcache was
also intended to cache deduced "facts"...)


    Feedback is welcomed,
    Ciprian.


    P.S.: My Prolog is **extremely** rusty, thus if I've done horrible
mistakes please let me know...  :D