On Sun, 2 May 2010, Howard Chu wrote:

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

Well, for example the bits are used when trying to find existing connections
to re-use as then the bits must match for the connection to be considered. If
those RTMP differences are in fact different on the wire then I think they
might need different bits for that purpose. But ConnectionExists() *could*
also be adjusted/customized for this particular purpose although it wouldn't
be too pretty...

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

Right, so we can start out with the easy way for now and see if we bother
later on to make it somewhat smarter.

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

Basically, yes. It depends a lot on how the underlying library works too.

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

libcurl wants all operations to work non-blocking, and that's what imposes the
rules on the protocol code. You can do everything you want as long as you
don't block - some parts still block but they're not considered "nice"...

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

libcurl doesn't have to re-implement what the 3rd party libs handle. libcurl
is more of a middle-ground to make sure things are coupled together correctly.
Again, as you can see in the SSH protocols, libcurl has a state-machine but it
is quite far away from the state-machine that the underlying 3rd party library
has. A different example would be the FTP code which is natively implemented,
so that of course has the entire state-machine for all protocol stuff.

I don't see how there's a way to avoid this and still provide the feature set
libcurl does.

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

Yes, that's the nature of most things libcurl does.

> I'm also wondering if RTMP is a good fit here or not.

...

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

Sure! Just ask if there's anything else I can help to clarify (or totally
confuse you with!) ;-)

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