Re: mirage + froc = self-scaling?

[Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx>]

On 9 Apr 2013, at 08:34, Raphael Proust wrote:

> On Tue, Apr 9, 2013 at 12:44 AM, Daniel Bünzli
> <daniel.buenzli@xxxxxxxxxxxx> wrote:
>> Having read that discussion, I'm interested to know if there's any 
>> particular reason on why froc was preferred over react as there is already 
>> support for react in lwt (though how that materializes exactly is unknown to 
>> me) and react's behaviour with respect to threads is well-documented [1].
> 
> I don't know why "froc was preferred over react" (I've only ever used
> react myself), but here are some things you might be interested in
> knowing:
> 
> - there might be a switch to Async or even a parametrization over a
> co-op threading monad
> - it is not clear yet that we want the two layers (frp and co-op
> threading) to mix/interleave
> 
> About the second point: to guarantee that the data-plane (IO-plane) is
> always fast, we want to keep the configuration-plane out of the way as
> much as possible. As we envision using frp for configuration, there
> might be benefit from the separation of frp and co-op threading.
> 
> AFAIK details about this are still being discussed.

from my point of view, i'm marginally more familiar with Froc than React (which 
i don't know at all); there's a comment in the Froc "tutorial" blog post 
concerning control dependencies (claiming React doesn't have a mechanism for 
them where Froc does); and to confirm what raphael says above, at this stage 
we'd like to keep the FRP and threading layers very clearly separated while we 
work out what we want to happen here, so the existing integration probably 
isn't immediately useful.

having said all that, to turn your question around, are there strong reasons to 
prefer React over Froc?  i'm still learning about FRP so happy to have 
discussion about this :)

-- 
Cheers,

R.




This message and any attachment are intended solely for the addressee and may 
contain confidential information. If you have received this message in error, 
please send it back to me, and immediately delete it.   Please do not use, copy 
or disclose the information contained in this message or in any attachment.  
Any views or opinions expressed by the author of this email do not necessarily 
reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.