Re: generalising oxenstored for unix nodes too

[Raphael Proust <raphlalou@xxxxxxxxx>]

My internship is almost over and I won't have time to contribute code in the
immediate future. I'll keep an eye on this and contribute (in code and thought)
later though.

In the mean time, some thoughts:


#Interaction between FRP and xenstore

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?

Allowing such a use is nice as it makes it possible for one to export
non-primitive values directly in the tree. But allowing is complicated as it
requires the transaction mechanism to integrate FRP bits and FRP make
assumptions of atomic re-computation of the whole graph of values. Some values
might only be computable on the store client, which makes the sharing of the
name-space difficult.

There are several approaches to this problem, but some break FRP invariants or
induce blocking operations. Still need to think about that.


#bind(1)

Reading plan9-related stuff, I stumbled upon the bind
http://plan9.bell-labs.com/magic/man2html/1/bind operation on the namespace. In
plan 9 it is used to replace $PATH (and other $MANPATH, $CDPATH, etc.)
and also to share values.

The implementation would require modification to xenstore and its API, but it is
really a nice thing to have on a namespace. It might also be a way to loosen
the constraints induced by the FRP aspect. (Exposed FRP values could be bound to
the 'observer' sub-tree with a not-always-up-to-date semantic.)



Cheers,
-- 
_______
Raphael