1211489 - Provide message sequencing in Marionette

Assignee

Description

•

9 years ago

Message sequencing allows Marionette to provide an asynchronous, parallel pipelining user-facing interface, limit chances of payload race conditions, and remove stylistic inconsistencies in how commands and responses are dispatched internally. Clients that deliver a blocking WebDriver interface are still be expected to not send further command requests before the response from the last command has come back, but if they still happen to do so because of programming error or otherwise, no harm will be done. This will guard against bugs such as bug 1207125. I also intend to formalise the command and response concepts, and in particular apply these concepts to emulator callbacks which for long have been a wart in Marionette. Through the new message format, Marionette will be able to provide two-way parallel communication. In other words, the server will be able to instruct the client to perform a command in a non ad-hoc way. runEmulatorCmd and runEmulatorShell are both turned into command instructions originating from the server. This should resolve a lot of technical debt in the Marionette server code because they are no longer special-cased to circumvent the dispatching technique used for all other commands; commands may originate from either the client or the server providing parallel pipelining enforced through message sequencing: client server | | msgid=1 |----------->| | command | | | msgid=2 |<-----------| | command | | | msgid=2 |----------->| | response | | | msgid=1 |<-----------| | response | | | The protocol will consist of a "Command" message and the corresponding "Response" message. A "Response" message must always be sent in reply to a "Command" message. The command message is a four element array: [type, msgid, name, params] type: Must be zero (number) indicating that it is a "Command" message. msgid: Sequence number. The opposite remote replies with a "Response" message with the same number. name: Method/command name to perform. params: Arbitrary object with arguments to the command. The response message is also a four element array: [type, msgid, error, result] type: Must be one (number) indicating that it is a "Response" message. msgid: Sequence number corresponding to the command message. error: If the command was executed correctly, this field is null. Otherwise it is an arbitrary object representing an error. result: Arbitrary object if successfully executed. If an error occurred, this field is null. These changes will require bumping the Marionette protocol level and making some changes to existing clients. The changes should however be minimal, since the data structure of the response from the commands isn’t changing.