PEPmodel Demo Documentation

PEPmodel is a sample PEP implementation written in Java. A client, proxy, and server act as testbed applications to invoke the PEP library code and a set of extensions. The source code  is intended to be more readable than efficient. The class hierarchy parallels the (intended) class structure for the more efficient Jigsaw implemenation.

The PEP library manages and dispatches a set of PEP extensions. These extensions enhance the functionality of the web agents.

Scope of PEPmodel

PEPmodel addresses the PEP model at all of its levels. Consider a transaction like this:
Client says:

GET /countable/asdf.html HTTP/1.1
PEP: {{map "http://pfunk.w3.org/src/classes/AccessCounter.html" AccessCounter-12345}{strength must}}
AccessCounter-12345: 7

HTTP/1.1 200 OK
AccessCounter-12345: 3.1415
Content-Length: 201
...

• header name arbitration - PEP reduces the header vocabulary to a set of well known headers as published in the HTTP/1.1 spec..
• additional headers are mapped for a specific transaction with a PEP mapping. This solidifies header identity at two levels:
• insures unique header names - PEP extensions are granted unique header names by the agent.
• takes advantage of the uniqueness of URLs to insure uniqueness of headers functionality..
• dynamic extensions - Because extensions are uniquely identified by URLs, an extension interface may be adopted and the extensions may be automagically retrieved and executed. This leads to challenging security issues.

coding styles

• Obscure abstractions were avoided to make the code more readable as files or in a debugger.
• wide formatting - any text on lines that are too wide to see is  intended to be less important details. The hope is that the purpose of the line is clear in the first 80 columns.
• simple coding - some efficiency was sacrificed in order to make the code more readable. For instance, the header fields are are handled as strings rather than a more clever list of substrings.
• one error message - the server has has only one error messages body.
• no custom exceptions - I just throw the standard java exceptions
• minimal classes - no extra methods have been added to round them out, just what was needed.