2011-11-14, 11:11
Currently there is no parallelism or anything and every request is stalled until the previous request has been finished but in the future we are planning to handle requests in seperate threads. This makes it possible to execute fast requests while slow requests are still being processed (e.g. calling JSONRPC.Ping while VideoLibrary.GetMovies returns 1000+ movies etc).
So if you want to be on the safe side (i.e. future proof) you need to wait till you got the response for the Player.Open request before sending the Player.Seek request. The JSON-RPC 2.0 specification states that it is not required to keep the order of requests even in batch requests.
For the particular case of resuming playback I am planning to add a "options" parameter to Player.Open which will allow to specify a resume point.
So if you want to be on the safe side (i.e. future proof) you need to wait till you got the response for the Player.Open request before sending the Player.Seek request. The JSON-RPC 2.0 specification states that it is not required to keep the order of requests even in batch requests.
For the particular case of resuming playback I am planning to add a "options" parameter to Player.Open which will allow to specify a resume point.