29: Arranging a Meeting Between Agents

  1. Once an agent has entered a place, it can use the place's features because it has a reference to the place (using the "here" specifier). It can't use the features of agents co-occupying the place, however, unless it arranges a meeting with one or more of those agents or gets a reference to an agent in some other way.
  2. Requirements of the place and agents for meeting.
    1. Agents can't meet unless they occupy a place defined using the MeetingPlace mix-in.
      1. MeetingPlace provides meet, part, and partAll operations.
    2. Any agent can be a petitioner and call meet on a meeting place.
    3. An agent can't be a petitionee unless has been defined using the MeetingAgent mix-in.
      1. MeetingAgent provides a meeting operation that is called by the engine if the agent satisfies the petition of a petitioner.
  3. Creating a petition to arrange a meeting
    1. A petition's attributes request a meeting with a specific agent.
      1. One identifies the petitionee's class.
      2. One identifies the telename of the petitionee.
      3. One specifies a maximum amount of time the petition will wait for the meeting to occur.
    2. A petition can carry nil values for any of these attributes, so the petition can be very specific or extremely vague--depending on how much information is included in the attributes.
      1. You can subclass Petition to add more info if you desire.
    3. Using the petition to request a meeting.
      1. An agent calls "meet" on its place of occupancy and supplies the petition as an argument.
      2. The engine calls "meeting" on an agent that satisfies the petition. It provides the telename, class, and petition of the petitioner. The petitionee can then (depending on how its meeting method is defined) decide whether or not to accept the petition.
      3. If the petition is accepted, the petitioner receives a reference to the petitionee, and can then use the petitionee's features. The petitionee has a reference to the petitioner, and can use the petitioner's features as well.
      4. If the engine can't find an agent to satisfy the petition or the petition expires (it takes too long to find a petitionee), the meet operation throws an exception.
    4. A petition is satisfied by any agent that matches the required name and class.
      1. If a petition is flexible enough to be satisfied by more than one agent, the engine approaches each agent in turn until one accepts the petition or until all have rejected the petition.
  4. Why an agent may not be able to meet (another cursory look at process control)
    1. An agent must be in full or partial control before it can request a meeting--that is, it can be running foreign operations that aren't currently executing (more details in Multitasking chapter.)
  5. Multiple meetings
    1. The engine creates a separate thread of execution for each "meeting" operation it calls on an agent, so an agent can meet with multiple agents simultaneously. (See Multitasking for more details on threads.)
  6. Recording a meeting
    1. When a petitioner calls meet, it passes a record object along with its petition. The engine stores it as the petitioner's record of the meeting. The petitioner can change the object as the meeting progresses to record the activities of the meeting.
    2. When a petitionee accepts a petition with its meeting method, it returns a record object to the engine. The engine stores it as the petitionee's record of the meeting. The petitionee can change the object as the meeting progresses to record the activities of the meeting.
  7. Ending a meeting
    1. When an agent wishes to end its meeting with an acquaintance, it calls "part" on the meeting place (or "partAll" to part from all of its acquaintances).
      1. The engine sends a PartEvent signal to the affected acquaintances who can receive the event and act on it if they wish.
TS Ref - 26 JUN 1996

Generated by the sweat of Mike Boom's brow.