Node:Membership and Reading, Previous:Security, Up:Concepts


Membership and Reading

Persons' memberships in conferences are represented in the protocol as arrays of Membership-typed values. This structure contains information about how and when the membership was created and which texts have been read in the conference.

There are two kinds of memberships. An active membership indicates that the person is actively participating in the conference, wants to know if there are unread texts and wants to receive messages send to the conference. A passive membership is similar to no membership at all. The person is still a member but will not receive messages sent to the conference and will not be notified when there are new texts. From the user's perspective, passive membership should be like no membership at all, but the server still remembers what the user has read in the conference while he or she was an active member. Since protocol version 10 a bit in the membership type field of the membership structure indicates the type of membership. Previously the server did not support passive memberships, but there was a convention that clients should treat the priority level zero as a passive membership.

The membership record indicates which texts have been read through the read-ranges field, which contains a list of ranges of local text numbers that has been read.

Finding out which articles a person has read in a particular conference requires a few calls. Normally, a client will retrieve a batch of perhaps 50 articles at a time. The outline of the process is as follows:

  1. Fetch the membership to get the read-ranges.
  2. Use local-to-global to translate a number of local numbers to global numbers.
  3. Remove the global numbers corresponding to local numbers contained in read-texts from the result.
  4. Get and translate more texts as needed.

The process is complicated because of the translation between local and global text numbers. If the server does not implement the local-to-global call, it is possible to use the less efficient but perfectly serviceable get-map call instead.