[FFmpeg-devel] Controlling the server reply (was: 9/9] doc/example: Add http multi-client) example code

[Nicolas George]

Le quartidi 24 messidor, an CCXXIII, Stephan Holljes a écrit :
> the best thing I thought of was some kind of generic communication
> function that either uses the client's AVOption system to pass around
> values or just uses an AVDictionary.
> Giving the application access to the results of the library could be
> done in a similar way it is being done in http_read_header() by
> repeatedly calling the communicate function and checking for its error
> code (return < 0 in case of error, > 0 in case of success, but
> unfinished processing and 0 on success and finished processing.) Since
> we have to deal with protocol-specific decisions, each protocol should
> implement its own communication function with something like a
> url_comm_params() function added to the URLProtocol struct, which is
> called like most (all?) other URLProtocol functions with
> ffurl_comm_params() and avio_comm_params(). I'm not really sure how to
> tell the application what parameters were negotiated, but maybe this
> can be done in a similar fashion it has been done with unused_opts,
> but instead with used_opts.

This is more or less what I had in mind.

To hold the options, I believe the AVOption system is better, because it has
types: using AVDictionary would require converting everything to strings.

Furthermore, AVOption object have inheritance, that can be used to access
parameters in nested protocols: if the HTTP context inherits from the TCP
context, getting the IP address is transparent; the same applies to TLS
parameters with appropriate inheritance.

As for the communication function, I believe it can just be url_handshake()
/ avio_handshake().

In other words: if avio_handshake() returns 0 that means the handshake is
finished, it if returns >0 that means the handshake has progressed by one
step but is not finished, and of course <0 means error.

(We could try maintaining the convention that the return value is
decreasing: 2+x for the underlying protocol, 1 during the headers. I am not
sure if this would be very useful. It may also be a bit of trouble to
maintain if the underlying protocol handshake is not the first step or if
there are several underlying protocols, but I suspect these cases will not
happen.)

As for notifying the application of received parameters: this is not
speed-critical, so the application could just repeatedly check if the option
is still NULL or any corresponding default value.

Does that sound ok to you?

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150713/79ec540c/attachment.sig>