Daniel Stenberg wrote:
> On Sun, 2 May 2010, Howard Chu wrote:
>
>>> This looks... special. What's the need for adding RTMP as five protocols?
>>
>> Well, it has at least those 5 URL schemes in common use. I assumed I needed
>> one per scheme. rtmp:// is the plain protocol of course. rtmpt is a special
>> variant tunneled in HTTP. rtmpe is Adobe's version of encrypted rtmp (I
>> hesitate to use the word "secure" since it clearly isn't...), rtmpte is
>> rtmpe inside the HTTP tunnel. rtmps is rtmp inside an https tunnel. (So
>> technically it ought to be "rtmpts" but Adobe just calls it rtmps.)
>
> Aha, thanks for explaining. We haven't yet added anything like that so I guess
> we either do it as five protocols, or we do some new cleverer arrangement. I
> guess we can do it the easy way first as give protocol entries, at least five
> protocol handler structs, quite possibly they won't all need their own
> protocol bits. Or am I wrong?

Heh, I was hoping you could tell me, I don't know what depends on these bits.

Looks like LDAP has only 1 bit, so I guess you only need multiple bits if
libcurl itself handles all the details. If that's true, then with librtmp we
should only need 1 bit.

[re: cleverer arrangement - change the Curl_handler.scheme to a
NULL-terminated const char **schemes, and provide the integer index of the
matched scheme as one of the connection parameters... I guess it's not a big
deal either way. ffmpeg also does one structure per protocol, so I'm used to
it by now.]

>> I'd like to try to avoid the one-shot approach used by the ldap handler, but
>> I'm not sure how to fit into the Transfer() processing. RTMP is, like LDAP,
>> a binary message-based protocol. We can't just setup the connection and then
>> let Curl_readwrite() / readwrite_data() pass the data straight from the
>> socket to Curl_client_write().
>
> RTMP would perhaps be more like the SSH-based protocols? They're binary and
> message-based and "done right" in regards to how they are done within libcurl,
> as they are fully supported using both the easy and the multi interface etc.
> It does require a state machine so that it never blocks.

Hm... So you need to define a state for every step that can trigger a socket
I/O? That could get pretty tedious. Is it really all-or-nothing like this, or
can we lump some of the steps together into potentially blocking chunks?

Obviously 3rd party libraries already handle their necessary state changes, it
seems like redundant effort to implement them again in libcurl.

>> Speaking of the ldap handler - I can't imagine that it actually gets much
>> use. Does it?
>
> Not a lot, no. But I've got the impression that it is still actually used
> though and that's why we haven't just cut it out. It is a bit of a stranger in
> the libcurl family.

Yeah, it doesn't strike me as fitting very well in the general theme. Of
course I'm having doubts about RTMP as well. Most of the protocols you already
have implemented are used for bulk data transfer - make a request, get a byte
stream back. LDAP requests are a bit more structured, and the fact that you
actually need to postprocess the network data into LDIF makes it a bit
different in that regard.

I'm also wondering if RTMP is a good fit here or not. It makes sense in a
media player framework since media streaming is its sole purpose. (So
integrating it into ffmpeg, mplayer, and XBMC made a lot of sense.) Some of
the features that justify its existence are that it lets you seek forward and
backward in a stream, or transparently switch between streams of different
bitrates while playing, but none of that would mean anything here.

I'll need to study the libcurl code and think about this some more...

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html