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 <[email protected]>wrote:
> On Fri, Jul 5, 2013 at 1:56 AM, Sean Charles <[email protected]> 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
>
_______________________________________________
Users-prolog mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/users-prolog
