From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id D09C1BC37 for ; Wed, 9 Dec 2009 19:00:51 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYCAOd0H0tV2gB5h2dsb2JhbACEJpRdgl0BAQEKCwgHFas+kCOBL4IqUwSDF4YA X-IronPort-AV: E=Sophos;i="4.47,369,1257116400"; d="scan'208";a="41699782" Received: from emailfrontal2.citycable.ch ([85.218.0.121]) by mail1-smtp-roc.national.inria.fr with SMTP; 09 Dec 2009 19:00:51 +0100 Received: from [192.168.0.12] (unknown [85.218.92.99]) (Authenticated sender: guillaume.yziquel@citycable.ch) by emailfrontal2.citycable.ch (Postfix) with ESMTPA id B0DDFB104C4; Wed, 9 Dec 2009 19:00:44 +0100 (CET) Message-ID: <4B1FE5E0.2020506@citycable.ch> Date: Wed, 09 Dec 2009 19:01:04 +0100 From: Guillaume Yziquel Reply-To: guillaume.yziquel@citycable.ch User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707) MIME-Version: 1.0 To: Richard Jones Cc: =?UTF-8?B?RGFuaWVsIELDvG56bGk=?= , OCaml List Subject: Re: [Caml-list] Re: Recursion on React.events. References: <4B1F0E3A.3040907@citycable.ch> <91a3da520912082353m5c75f307j6f9542877d84841f@mail.gmail.com> <20091209112316.GA15607@annexia.org> In-Reply-To: <20091209112316.GA15607@annexia.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; guillaume:01 guillaume:01 recursion:01 gtk:01 daniel's:01 gtk:01 windowing:01 windowing:01 semantics:01 daniel's:01 low-level:01 implements:01 semantics:01 parser:01 parser:01 Richard Jones a =C3=A9crit : > On Wed, Dec 09, 2009 at 03:53:36PM +0800, Daniel B=C3=BCnzli wrote: >>> Daniel B=C3=BCnzli'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 [...] >=20 > 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. >=20 > Rich. Concerning documentation, Daniel's documentation is pretty good, and=20 it's all that's been necessary to get me going. You should try having a=20 look at it. I have little experience with Gtk, but I've written an Eliom web=20 application using the ExtJS framework for windowing in browsers. In some=20 sense, it's more complex than a Gtk application, because you have to=20 manage lots of users, sessions, et ceter=C3=A6. Moreover the Eliom module was keeping track of the state of an Asterisk=20 server, and initiating phone calls. I must say that using React was the only way to write the application=20 cleanly and in a minimum amount of time. I was basically using signals for: -1- proxying persistent information such as user data and configuration=20 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=20 with it (making phone calls, when the phone hangs up, when a call could=20 not be made, etc...) -4- Keeping track of the IP of users of the web application coming from=20 Ocsigen, and reconciliation with the IP of the softphones as registered=20 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=20 feed it back to the administrator's web session -6- Doing all the "real-time" AJAX interaction for updating tables,=20 windowing, et ceter=C3=A6. Doing it in a FRP way allowed to focus on the semantics, and moreover=20 React update cycles integrate nicely with Lwt as used by Ocsigen. So you=20 can do really cool stuff with it. It took me roughly one and half to two=20 weeks from scratch (including learning the ExtJS library,=20 troubleshooting the Asterisk Manager Interface, et ceter=C3=A6), with qui= te a=20 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=20 in the sense that it implements the bare mechanics and semantics of FRP.=20 For real world application, you have to be quite nifty with tricky=20 details about update cycles. For example, make a parser of the Asterisk=20 Manager Interface with React around OCamlNet's Uq_engine module proved=20 to be quite tricky, in a similar way as the issue that started this=20 thread (here, I had no event, but in the Asterisk parser, I had doubled=20 events, and I solved it in a very very ugly way). It's true that I may not completely understand how React works, as=20 Daniel stated it before (a bit better now), but, for instance, the=20 React.E.switch or React.S.switch is something that you'll be using a=20 lot. And I feel the need for higher-level functions to deal with it,=20 even though I do not have yet a precise idea of which such functions. All the best, --=20 Guillaume Yziquel http://yziquel.homelinux.org/