The behavior of constructors in IPDL

I'm trying to understand the behavior of constructors in IPDL. Please
correct me if any of the following statements are incorrect:

*  A sub-protocol must be created using the constructor method in the
manager protocol

* When the constructor is asynchronous, it doesn't behave like other
asynchronous messages: there is an undeclared response message which gives
the sending message the child routing ID of the new protocol.

* There is currently no callback function for protocol implementers to know
when an async constructor has gotten the response message with the child
routing ID.

I think that this model doesn't match the way people are going to expect to
program, especially when everything is asynchronous. For example, if you're
modeling this networking call asynchronously:

network->NewChannel(nsACString& spec, nsIChannel **result);

The protocols would be:

protocol Network
{
  manages Channel;

parent:
  NewChannel(nsACString spec);
};

Apart from wishing that the method name were "NewChannel" and not "Channel",
I need to have a notification (on ChannelProtocolChild) when the Channel
object is ready to use, *or* I need the code to accept and queue message
calls on the Channel before the child routing ID is received and send them
once the channel is actually ready.

Chris, you said in https://bugzilla.mozilla.org/show_bug.cgi?id=506075#c4
that the routing IDs will be different on the child and the parent and
that's why you have to have a response message. I don't understand why this
has to be the case. Instead, can't the side which is creating the actor
create a new serial ID and send it to the other side, e.g.

protocol Network
{
  manages Channel;

parent:
  NewChannel(nsACString spec) returns (new Channel);
};

If both parents and children can create the protocol, a flag bit could be
used to distinguish between them and avoid races creating routing IDs.

--BDS