[Spread-users] group membership

[Yair Amir]

Hi,

In my opinion, answering questions such as "which group am I a member of / who are the members of a group I belong to", should be a library-only call. The library should just remember the group information that it delivers. (To be able to get valid answer, the connection will have to require group membership information of course).
Note that these calls are only convenient calls because the answers are based entirely on information that the application already got from Spread. I agree though that several people asked for it so it might be a worthwhile addition to the library and the Java class.

Questions such as "which groups are in the system / who belongs to a group I am not a member of" have to be answered by the Spread daemon itself, if at all: The Spread daemon is the authority about this. It is unnecessary to complicate the system by having a separate process maintaining "cache" for this. The question is: should anybody be allowed to query membership of groups they are not members of? This should probably wait for the new access control mechanisms... I would appreciate some real-life example for a need for such calls.

    Thanks,

    :) Yair.


Julien Dufour wrote:

> 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
>
> _______________________________________________
> spread-users mailing list
> spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users