In order to allow multiple apps to use the same stack, we can no longer
make the assumptions that :
- our app is the only one using the current WADI stack
- that the set of apps on all cluster members is the same all the time
(some may be being redeployed)
In order to deal with both issues in the cleanest and most consistent
manner, I am proposing that we consider extending our group API and
implementations to support 'subsetting'...
e.g.
We introduce the concept of a PeerSet.
A Cluster maps to the UniversalPeerSet - a special type of PeerSet.
UniversalPeerSets may be used as factories to produce PeerSubSets -
another type of PeerSet.
Anything in WADI that is currently using a Cluster, should be changed to
think in terms of a PeerSet.
UniversalPeerSets continue exchanging messages and being notified of
changes within their membership, state etc...
PeerSubSets register with their parent UniversalPeerSet and percolate a
relevant subset of these notifications down to their own members.
In this way, I hope that with a relatively small amount of work, a
number of WADI apps will be able to run either independantly on their
own JG/AC/Tribes stacks, or share a single stack without knowing the
difference...
Does anyone have anything to add before I dive into a sandbox somewhere
and find just how difficult this is to achieve :-) ?
Jules
--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."
/**********************************
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
* www.coredevelopers.net
*
* Open Source Training & Support.
**********************************/
