Interface

Objectives

• Provide a uniform access interface for the set of extensions that were implemented
• Choose that set to demonstrate how large the extension interface could be and how large it would be practical.
  • AccessCounter - most basic extension, demonstrates the recall of Instance data spanning multiple connections.
  • Escape - should have the same needs as any stream filter.
  • RemoteControl - Shows how an extension could have very customized interface needs. In this case, it needs to be passed an object that allows it to shutdown or restart the server.
• Demonstrate a standardized dynamic interface that meets the needs of a reasonable subset of the above extensions.
• Maintain a language independent interface between the pep library, party (client, server, proxy), and extensions.

Custom interface needs, like those for RemoteControl, would be very difficult to accomodate without a negotiation scheme like IUnknown in DComm. Clients and servers may hard-wire this kind of extension, while still providing a rich enough interface to support dynamic extensions. This sequence document shows a sequential view of an inclusive interface.

Callbacks

Because PEP extensions vary, the extensions must be able to be called many times during the processing of a message. The same interface functions are called but a state parameter is passed to distinguish callbacks made during the different states:

• CONNECT - called when teh connection is first established and before the request or status line has been passed. This is useful for binary transports that supplant HTTP.
• STARTLINE - called after the first line has been transfered, but before and headers have been passed. This may be useful for binary header transports.
• HEADERS - after all the headers have been transmitted, but the body has not been started. This is good for a standard PEP stream extension.
• BODY - called after the body has been transfered.

PEP model extensions have a consistent interface as described in the PEPExtension module. A description of the calling context is shown in the Annotated Stack Trace.

Language independence

Some effort was made to keep the interface between the pep library and the extensions language-independent. For instance, PEPAgent.makeInstance's call to checkExtension.makeInstance could have been done more expeditiously by passing a Vector or Enumeration, but these types don't have clear analogs in standard C. This restriction is intended to make code transliteration or inter-language interfaces easier.