[Spread-users] group membership

[Julien Dufour]

On vendredi, juin 1, 2001, at 05:32 , Jonathan Stanton wrote:

> The one trick is to keep the information "accurate" (within the 
> limits of
> any asynchronous system). If this modular interface relied on 
> the "query"
> function to get its information it could be quite out-of-date because
> changes to the group happen between queries. The only way to stay
> "current" is to have the modular interface join the group itself and
> monitor membership messages,

That's what I thought, I should have clarified this point.
The tool gets membership messages by itself and keeps data up to date.
Moreover, it only keeps information about joined groups in its cache.

>  or, to have the client who did join the group
> pass all membership messages it receives to this modular cache.

This way looks bug prone to me.

> The first approach is the easiest on the client and the cleanest, it
> just adds additional members to each group. The second doesn't add
> extra members but requires the client application code to keep the
> cache updated.

There is no need to add extra members to the groups. I named the 
tool with the term "library" because I think it should simply be 
a layer between applicative code and spread library integrated 
to the project. The tool would be just another listener of the 
membership messages (I only use Spread with Java, I don't know 
if the listener design pattern is included with others 
languages).

Making the tool standalone would allow to share the data and 
save some memory space (computations are light, then it isn't an 
issue). It would then require some extra members.

Using one or many integrated tools or a standalone one is a 
project design choice, so the extra members should then not be a 
problem as they should be part of the design.
--
Julien Dufour
Posse42