Changes

The PDL compiler will take as input a FooProtocol.pdl source and generate FooProtocolServerFooProtocolParent.h and FooProtocolClientFooProtocolChild.h C++ headers. These headers will declare message types for the transport layer, declare protocol states, and define functions that take care of state transitions and invoke message handlers. The headers will leave undefined the ''implementations'' of message handlers; these are up to mozilla provided by code to provideutilizing the protocol actors. (Perhaps through subclassing.)

Message handlers will be responsible for processing the received message (obviously) and also deciding which of the allowed states is transitioned to after processing. The generated protocol header will enforce protocol safety here. Lower-level enforcement of transport-layer properties, like not nesting asynchronous calls within synchronous handlers, can be enforced in a shared ProtocolBase class. '''TODO''': should these kinds Hopefully much of properties be global, or defined in protocol specs? this we can check statically. What are all Some of these properties? Deadlock avoidance is another, if we provide are* not nesting asynchronous calls within synchronous messages.handlers* avoid deadlock* don't fill the underlying pipe (rate limit)

Protocol safety (only sending/receiving allowed messages from particular states) will be enforced by generating a finite-state machine in the protocol header, and checking sent/received messages and transitions against this state machine.

Very importantly, there An ''actor'' will just be an implicitlyinstance of a protocol server or client class. We need some way of addressing particular actors across threads and processes. Hopefully the chromium IPC code already supports this. Also, we can easily support process-to-process and thread-defined ERROR state to-thread communication over these protocols. The latter would be very useful for debugging, and also useful for writing threaded code that occurs avoids shared memory as much as possible (even when an actor violates the protocol (or a type safety constraintwe have multiple processes we will still have multiple threads). How Due to its apparent difficulty, this is handled is very much open to discussiona low-priority TODO.

'''NOTE''': I think it's worthwhile leaving error detection on even in optimized builds. It should be quite cheap compared to IPC overhead and Protocol instances will likely allow us to avoid security-related bugs. An ''actor'' will just not be an instance of a protocol server or client class. We need some way of addressing particular actors across threads and processes. Hopefully thread safe in the chromium IPC code already supports this. Also, we can easily support processusual multi-to-process and thread-to-thread communication over these protocols. The latter would be very useful for debuggingthreaded, and also useful for writing threaded code that avoids shared -memory as much as possible (even when we have multiple processes we sense; they will still have multiple threads). I '''do not''' think that protocol instances should instead be "thread safe (" in the usual sharedsense of HTML5 Worker Threads: share-memory sense)nothing. We should use these protocols to avoid this kind of multi-threaded code, whether inshared-process or out-of-processmemory code.