A group is actualy two things:
its definition: ID, list of services and transports, pointers to implementations, name, keywords, initial app.
its instantiation on a given peer: Peer ID, Peer Name, parameters for transports and services, optional roles such as rendezvous and routers, etc.
Some even argue that the information about the peer should go into a third document. However, that's just the peerId and peerName, and the peerId would have to be used as a referrence anyway, so I'm reluctant.
Currently we put all this information in the same document. It may be simple - code wise, (in fact, I just did not think about it, then :-), but it is quite wastefull because both types of information are used in different contexts and for different purposes. You'd need the group definition in order to instanciate it on some peer, while you'd need particular instanciations in order to communicate with peers running that group. As a result the former needs to be published and cached in the surrounding group or wherever, while the later only needs to be published and cached within the group itself.
Also the definition can probably use a lot more eagerness in publishing and propagating than the instanciation. On top of that, they do not have the same optimal lifetime: the definition potentialy makes sense for a long time even if no peer currently instanciates it. On the other end, the description of a given instantiation is only usefull while the corresponding peer is up and can always be reobtained. So, purging it from a cache never does irreparable damage.
All these are very good reasons to separate this two sets of information in two independant types of advertisements. And that's one of the top items on my todo list, right after writting the present brain-dump.
My reason for bringing this up is that I have seen that someone was taking charge of the thorny item of expiring advertisments. The separation above encourages two different expiration policies, which, in my opinion makes the problem easier since that avoids the need for a policy that works for both types of information.
Last modified: Thu Jun 14 14:23:36 PDT 2001