caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Guillaume Yziquel <guillaume.yziquel@citycable.ch>
To: Richard Jones <rich@annexia.org>
Cc: "Daniel Bünzli" <daniel.buenzli@erratique.ch>,
	"OCaml List" <caml-list@inria.fr>
Subject: Re: [Caml-list] Re: Recursion on React.events.
Date: Wed, 09 Dec 2009 19:01:04 +0100	[thread overview]
Message-ID: <4B1FE5E0.2020506@citycable.ch> (raw)
In-Reply-To: <20091209112316.GA15607@annexia.org>

Richard Jones a écrit :
> On Wed, Dec 09, 2009 at 03:53:36PM +0800, Daniel Bünzli wrote:
>>> Daniel Bünzli's module is great, but sometimes a bit rough
>>> to get by, specifically on examples such as this one.
>> I would just like to point out that this has nothing to do with the
>> module per se but understanding frp in general [...]
> 
> Personally I've yet to read any comprehensible introduction to FRP.
> I'm interested in whether FRP can be used to write Gtk interfaces with
> reduced code complexity.  Apparently it can, but I've no idea how.
> 
> Rich.

Concerning documentation, Daniel's documentation is pretty good, and 
it's all that's been necessary to get me going. You should try having a 
look at it.

I have little experience with Gtk, but I've written an Eliom web 
application using the ExtJS framework for windowing in browsers. In some 
sense, it's more complex than a Gtk application, because you have to 
manage lots of users, sessions, et ceteræ.

Moreover the Eliom module was keeping track of the state of an Asterisk 
server, and initiating phone calls.

I must say that using React was the only way to write the application 
cleanly and in a minimum amount of time.

I was basically using signals for:

-1- proxying persistent information such as user data and configuration 
in the SQLite database

-2- parsing the output of the text-based Asterisk Manager Interface

-3- keeping track of the state of the Asterisk server, and interacting 
with it (making phone calls, when the phone hangs up, when a call could 
not be made, etc...)

-4- Keeping track of the IP of users of the web application coming from 
Ocsigen, and reconciliation with the IP of the softphones as registered 
by Asterisk (this allowed to avoid using passwords on the LAN)

-5- Keeping track of the history of the phone calls made by agent, and 
feed it back to the administrator's web session

-6- Doing all the "real-time" AJAX interaction for updating tables, 
windowing, et ceteræ.

Doing it in a FRP way allowed to focus on the semantics, and moreover 
React update cycles integrate nicely with Lwt as used by Ocsigen. So you 
can do really cool stuff with it. It took me roughly one and half to two 
weeks from scratch (including learning the ExtJS library, 
troubleshooting the Asterisk Manager Interface, et ceteræ), with quite a 
lot of other concurrent obligations to handle.

So yes, FRP is really cool.

Unfortunately, it seems to me that Daniel's module is fairly low-level 
in the sense that it implements the bare mechanics and semantics of FRP. 
For real world application, you have to be quite nifty with tricky 
details about update cycles. For example, make a parser of the Asterisk 
Manager Interface with React around OCamlNet's Uq_engine module proved 
to be quite tricky, in a similar way as the issue that started this 
thread (here, I had no event, but in the Asterisk parser, I had doubled 
events, and I solved it in a very very ugly way).

It's true that I may not completely understand how React works, as 
Daniel stated it before (a bit better now), but, for instance, the 
React.E.switch or React.S.switch is something that you'll be using a 
lot. And I feel the need for higher-level functions to deal with it, 
even though I do not have yet a precise idea of which such functions.

All the best,

-- 
      Guillaume Yziquel
http://yziquel.homelinux.org/


  reply	other threads:[~2009-12-09 18:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-09  2:40 Guillaume Yziquel
2009-12-09  3:22 ` Guillaume Yziquel
2009-12-09  4:25 ` Daniel Bünzli
2009-12-09 18:47   ` Guillaume Yziquel
2009-12-10  8:39     ` Daniel Bünzli
2009-12-09  7:53 ` Daniel Bünzli
2009-12-09 11:23   ` [Caml-list] " Richard Jones
2009-12-09 18:01     ` Guillaume Yziquel [this message]
2009-12-10  3:38       ` Daniel Bünzli
2009-12-10 22:24         ` Guillaume Yziquel
2009-12-11 12:16           ` Jérémie Dimino
2009-12-09 18:24   ` Guillaume Yziquel
2009-12-10  8:24     ` Daniel Bünzli
2009-12-10 21:41       ` Guillaume Yziquel
2009-12-11  1:22         ` Daniel Bünzli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B1FE5E0.2020506@citycable.ch \
    --to=guillaume.yziquel@citycable.ch \
    --cc=caml-list@inria.fr \
    --cc=daniel.buenzli@erratique.ch \
    --cc=rich@annexia.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).