[Spread-users] group membership

[Jonathan Stanton]

On Fri, Jun 01, 2001 at 04:29:20AM +0200, Julien Dufour wrote:
> 
> I agree with you. I think both methods are interesting.
> 
> The second one is mandatory in order to answer questions like 
> "Is X in group Y?" or "Who is in group X?" because the spread 
> library does not (and should not) own this information (the 
> client would have to be in every group...).

And even if it only monitored the groups the client was in, it mixes
interfaces. The current Spread api is designed to be a lightweight 
messaging api, not a full "everything you could ever want for distributed
applications" interface... 
> 
> However, this way raises performance and load issues:
> - The server has to be contacted for each request, which is "slow."
> - It would cost bandwidth, potentially a lot of it depending on 
> the request.

Yes.
> 
> The "utility" method is less exhaustive, but much more 
> efficient. I like this way because I think it can handle most 
> common cases (getting information about joined groups), the 
> implementation is trivial and moreover it is modular.

Just one trick. See below.
> 
> Both methods appear to be complementary. Writing some library 
> that would use both of them at the same time (the utility and 
> the queries) would be very useful. The library would keep track 
> of the membership of specified joined groups, dig into the data 
> in the first place, and would query the server when the data 
> don't hold the requested information.

I very much agree. I think this is a nice observation. I had thought about
allowing the queries to the daemon because it can be the ONLY way to
answer some questions, like "who is group Y" when group Y is not one you
are involved in. But using a modular data cache of current groups on the
client side can cut down on the network load a lot. 

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, or, to have the client who did join the group
pass all membership messages it receives to this modular cache. 

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.

Jonathan
-- 
-------------------------------------------------------
Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science   
Johns Hopkins University    
-------------------------------------------------------