Re: generalising oxenstored for unix nodes too

[Raphael Proust <raphlalou@xxxxxxxxx>]

On Sat, Feb 18, 2012 at 3:58 PM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> On Fri, Feb 17, 2012 at 09:47:42AM +0000, Raphael Proust wrote:
>>
>> In FRP there is a strong separation between primitive values (those that
>> can be changed by the "user") and the others (those that are updated
>> automatically to reflect changes of the values it depends one). There is
>> a choice one should make as to how mixing FRP and a namespace: should
>> non-primitive FRP values be allowed in the tree?
>
> This is a very useful insight. ÂIn Xen right now, pretty much all
> activities are initiated by the tools writing something into Xenstore, and
> then something else that is watching a path reacting on it. ÂOnce a user
> action has been kicked off, many other tools write keys into the store and
> use it as an RPC/select mechanism (e.g. for front and backend devices to
> connect between VMs).
>
> The interaction between these is very ad-hoc at the moment. Augmenting
> Xenstore to specifically understand that a given key is user-supplied is
> very useful.

Something else that might be useful (but may be overkill) is to have the store
aware of the dependencies. (E.g. this key is user supplied and may change
whenever this other key does.)

>
>> [â]
>
> The previous two points are tied together, I think. We need to figure out
> how to meld multiple writers (different VMs, different hosts, doesnt
> matter) and guarantee that we preserve the FRP equational invariants.
> Given that we have transactional isolation already and a purely functional
> tree that can be mutated non-destructively, this feels like it shouldn't
> be too hard.

Not sure about the not being too hard partâ There are tricky details.

I think there is a not too complicated approach that can work. Each participant
having a local copy is responsible for its coherency. The central store makes
new values propagate from one place to the other. This is less powerfull than
FRP in that some computation might be duplicated where they usually wouldn't be
(E.g. A changes a key, B and C initiate some computations and then push some new
values for some of theirs keys, C initiate some computations to take B changes
into account).



-- 
_______
Raphael