>> would it be feasible to have the stuff that you add 'protocol agnostic'?
>
> Well, we can't write the code agnostic but we could possibly make the API
> agnostic about the protocol. In fact, I don't forsee us add any pipelning
> API that requires the pipe to be using HTTP(S).
>
>> FTP can be pipe-lined also with some servers, the logic is the same.
>
> What are you talking about? FTP is quite different and I don't know of any
> standard (RFC959) or non-standard commands for FTP that offer anything
> near pipelining as it works for HTTP 1.1. Please enlighten me!
no RFC unfortunately, technically it is just that there is no need for
blocking in FTP and pipe-lining is told to 'just work' with some
implementations. but i could not find a clear doc on that (apart a page from
D.J. Bernstein but with no more references).

>> this pipe-lining is essentially what you described and nothing relies on
>> HTTP in fact, it is just that 'it works'... and it can also with FTP
>> servers. far from me to tell "just do it", but it would be cool to do the
>> HTTP pipe-lining stuff keeping in mind that the infrastructure should not
>> rely on HTTP itself.
>
> In general we don't close doors for making options and concepts work for
> multiple protocols and I don't have any plans to do it this time either.
> But I also don't have any plans to write any code or designs for
> pipelining(-like) functionality for non-HTTP protocols at this point.
> If anyone else feels like adding support for that, then that person is
> free to do so.
> But again: I'm not aware of any other protocol libcurl supports that
> offers pipelining.
i suppose that you are one of if not the main contributor of the project, so
sure do it your way, I cannot be there sitting on my chair telling 'it would
be cool to do that' and have over-expectations, i totally respect your
choices which are as for all of us linked to your resources and your
needs...

Armel
Received on 2006-06-24