On Thu, 21 Jan 2010, Chris Conroy wrote:

> My vote is for CURLOPT_INTERLEAVEFUNCTION/INTERLEAVEDATA since that captures
> the rationale for splitting it out into a separate function. If we're going
> to make this function name more agnostic, then we should probably have some
> sort of agnostic mechanism of setting the CURLOPT_RTSPREQ_RECEIVE since
> other protocols will need similar functionality.

I'm not really trying to make all options protocol agnostic, it was just the
fact that there was nothing in the interleave function's name that had to be
RTSP/RTP- specific at this point so we could just as well make it this way.

CURLOPT_RTSPREQ_RECEIVE is much more specific and it would make it much more
of a stretch to document that and use that in a way that isn't bound to a
specific protocol and its workings.

Of course, if you can think of a way/name that makes it more agnostic without
it sacrifising the RTSP way I'm interested.

> However, I'm not aware of any other protocols that follow this model since,
> frankly, it's not the best way to do things.

Right. And after all, if we come up with another protocol in the future that
would could make us of it, we can rename the option (and provide a
backwards-compatible define) to the more agnostic one THEN.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html