Re: Changing a protocol state based on returned values

Benjamin Smedberg wrote:
> I'm working on modeling plugin streams in IPDL. Plugin streams have several
> distinct modes of operation:
> 
> * Normal (browser writes data using NPP_Write)
> * Random (plugin reads data using NPN_RequestRead)
> * File+Normal (browser writes + saves data to a file)
> * File (browser saves data to a file)
> 
> The mode is determined by the plugin in the call to NPP_NewStream.
> 
> Is there, or could there be a way to statically/dynamically say that the
> IPDL protocol state of NPBrowserStream will be "any of these states
> determined at runtime"?
> 

I'll extend IPDL to handle this case.  Your NPStream protocol's state 
machine will be able to define multiple possible start states as follows.

   protocol NPStream {
     //...
     start state NORMAL:
     //...
     start state RANDOM:
     //...
   }

Because IPDL won't know which state to choose, your NPStream C++ ctor 
implementation will have to specify it.  The start state will be an 
additional outparam to an additional C++ "factory method".

1:  NPStream* ConstructNPStream(...);
2:  NPStream* ConstructNPStream(..., NPStreamProtocol::State* startState);

The returned state will obviously be checked against the set of 
allowable start states.

On the originating side, IPDL will initialize the start state to 
UNDEFINED and call factory method (2).  If the originating side wants to 
specify the start state, it can write the outparam to something other 
than UNDEFINED.  If it does, then on the receiving side, IPDL will call 
factory method (1) and automagically initialize the actor with the start 
state specified by the originating side.

If the originating side does *not* write the start state outparam, IPDL 
will assume that the receiving side wants to specify the start state, 
and IPDL will call factory method (2) there.  In this case, it would be 
an error for the receiving side not to specify a start state.

For the case where the receiving side specifies the start state, the 
actor constructed on the originating side will not be able to send 
messages until the reply comes back with the start state to use.  I.e., 
its start state will be UNDEFINED, and any attempt to send a message 
will violate protocol.

Until this change lands, I'd recommend defining your protocol as you 
want it, but leaving the "start" keyword commented out, like

   /*start*/ state NORMAL:

Cheers,
Chris