I’m using the Mobile Server API. In both the Connect command and (sometimes) in other commands I explicitly set the ProcessingMessage input parameter to Yes, but I never get responses that have a type of “Processing”, even when I am exporting an AVI. Are processing messages no longer supported?
Hi Richard,
Can you please specify which Mobile Server SDk you use (.Net, Javascript, Android, iOS) ?
Best Regards,
Svetlana
None of them! 
I’m using protocol integration, so the Mobile Server Protocol.
Processing messages are way http request to be supported alive. We’ve seen interesting client side behavior on particular platforms, when OS could decide to close the http request if the response (or at least part of it) is not received within X number of seconds. Something like HTTP timeout on OS level. The worst behavior in that direction is X to be 5 seconds. So MoS provides possibility to keep this particular HTTP request alive, which is handy for commands that are taking too much time to be processed by the server.
When that option is turned on, MoS sends periodic Processing messages on every 2 seconds.
However, if the command (request-response) completes for less time, such messages are not send.
Thanks Petar - yes, that’s what I thought it was supposed to do. But even when my command takes longer than 2s, I still don’t get any “Processing” messages. For example, StartExport has the option to send “Processing” messages but even though the export takes more than 2s, it still returns immediately.
Or does StartExport literally do that - start the export - and since that takes very little time, I don’t see any “Processing” messages? On what commands might I expect to see these messages?
Yes, Richard,
you second assumption is correct.
Command “StartExport” just triggers the export creation (including checking the required parameters, authorization rights, if there is recordings, etc).
But it does not wait for export to complete.
Actually for commands like StartExport, where we know that operation for sure will take much time, we just construct them in such way. So you have to trigger one, and check for the result later with another.
There are however commands that initially seemed to be such that should complete faster, but in some situations do not.
One example is GetSequences .
In most cases it finishes within milliseconds.
But as number of returned sequences depends on the actual recordings, as well of the actual customer HDD performance, and of the parameters provided in the request, there are situations where this particular command could take 10 seconds or more.
One option for it was to separate it on two commands like StartSequencesSearch and GetSequencesSearchResult. This however creates higher complexity, that is needed only for the lower percentage of the cases when execution of direct command takes much time.
So we decided for such cases to introduce processing messages.
We understand that such introduction moves the protocol away from the so popular REST interfaces principles. But you know there are pros and cons in everything 
Very true! Thanks for all the detail. 