[<<][sweb][>>][..]
Fri Apr 16 07:12:12 EDT 2010

Reactive Ramblings

When does this work?  To re-iterate one of the previous posts: this
approach is about _caching_.

  * If there is _significant computation_ between the model data and
    the query results, and this data can be re-used, caching (lazy
    evaluation) is a valuable option.

  * If in addition the model data changes _infrequently_ the lazy
    evaluation can be combined with a reverse-dependent invalidation
    step to get a _reactive_ program.

Note that when updates are frequent wrt. queries, it probably makes
little sense to keep an intermediate (cached) representation.


Let's move on with the reactive model for the ramblings.txt display.
The basic idea is this: given a set of files as input, and a
functional (data-flow) network that eventually ends in server queries,
construct a servlet that manages this structure.

Separate concerns:

  - abstraction of reactive network 
    (naive pull/push implementation: plt/rp)

  - abstraction of functional dependencies

  - file alteration monitor

  - controller for setup



Problem: what to do with create/delete?  Current assumptions are that
the dependency network is static.  Is there a way to propagate
"not-found" upwards?  Maybe invalidation is enough + handling of
"open" errors by the lazy eval.


Problem: how to encode the 2-step parsing?  I.e. I'm splitting a file
into a collection of atoms, with each atom depending on the original
file.  How to express this dependency?

The problem is that it is never allowed to "unpack" a reactive
variable.  Similar to monads..  So rv-force should be private!

Solution is to indeed 1. only unpack at the toplevel/output which
counts as _outside_ of the reactive network in the same way that file
alteration events are and 2. represent a collection as a finite
function / dictionary.



[Reply][About]
[<<][sweb][>>][..]