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?

> 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.

> 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.

> It wouldn't take me much effort to restructure it to be slightly more
> multi-friendly. Could at least break apart the result parsing loop. With a
> recent OpenLDAP library we could even delegate all of the connection setup
> to curl, and use its SSL setup instead of ours. (But I'll save that for
> another email thread, if it's worth pursuing.)

That does sound like some great ways to improve the LDAP sitation!

I'm not sure what we should use as metric to know if its worth it or not. I
would assume that current libcurl-LDAP is used only by a few rare users, but
quite possibly it might be used by more if it was converted to become a
protocol more in the same style and support-level as the others. But how can
we tell? It would be great if LDAP users on the list reading this would speak
up and let us know!

Also, I think our current LDAP sitation also reflects the somewhat low
priority the protocol has had among us libcurl developers.

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