When a node has something to share it thinks might be of general interest to the network, it wants to tell the world. However, we do not want to broadcast around every time we have something to tell.
The AWGPresence class manages this information in a more controlled manner. Local applications announce presence with the peer's 'presence' attribute (instance of AWGPresence). Every n seconds AWGPresence selects a peer and sends it all the deltas it collected, including the ones it received since the last swap from other peers. In effect this is very similar to the peer gossiping, although peer lists are restricted to a small set of peers, and presence information can in theory become very large.
Presence information is divided into presence sets, that each have a name (to please any people that want to move from Java to Squeak, we use reverse domain notation for the names - so presence of AardWorks DGV user policies is in the set 'nl.aardworks.dgv.community.policy'). Each presence set has a lease policy - presence times out, and if no-one refreshes (reconfirms) presence, the presence entry will disappear from the network. Stable stuff (files) should have long leases (typically a day or even more), volatile stuff (user presence) may have leases as short as 5 minutes.
As presence information is sent to all peers, eventually, and (currently) only kept in memory, care should be taken to announce only basic things. For example, one could announce directories to be present; an application protocol could then ask for the files inside the directory as they are needed.
Presence information consists of:
an 'object', typically a string identifying the object (username or filename, but apps may elect to put in UUID's in here for example);
an 'origin', the node that started announcing the presence (so where it is assumed that whatever is present, it is available there);
an 'endpoint', if applications elect to use this.
The latter is nice to announce services - our user policy example uses this to announce services by name after endpoint registration; when someone needs to access the policy service a lookup by name can be done, and a random instance of the service can be contacted directly on the indicated origin:endpoint combination (a random instance if more than one is registered - a presence entry is unique on object+origin so duplicate objects will be propagated across the network, nice for redundancy).
