* Daniel Stenberg <daniel_at_haxx.se> [Fri, 25 Apr 2008 00:10:48 +0200
(CEST)]:

> That's pretty much exactly what CONNECT_ONLY does today!

Oh... hmmm... sorry, I have missed that. Connecting and getting the
descriptor is almost exactly what I wanted.

Still, I have some doubts:
- it is not clear how should I close the socket after use;
- is it a blocking socket?
- I must handle timeouts, network errors and all such myself;
- in case of SSL connections, which descriptor is returned? The socket
connected to the server, or the SSL engine's handle?
- under Windows, should I use socket-oriented or file-oriented
functions? And what about SSL connections?

I still think that libcurl can handle its sockets better than the
application - simply because libcurl knows more about the socket.
Providing an interface for sending/receiving the data will greatly
simplify the usage of libcurl in aplications using CURLOPT_CONNECT_ONLY.

> > 'send' and 'receive' (I am dreaming here) work with curl handles,
not
> > sockets. Thus, it will be easy to write applications implementing
custom
> > network protocols, yet capable of working though proxies and SSL
> > connections.
> >
> > I guess that this (or similar) functionality is already in the guts
of
> > libcurl, but is not usable from outside. Wouldn't it be great if
there
> > were some public interface to send/receive data?
>
> I guess it could be useful, but for people wanting other and different
> protocols, why would they use libcurl at all in the first place?

Do you really need reasons? :) Just open the features page -
http://curl.haxx.se/docs/features.html - and pick just anything under
"libcurl". Stability, URL groking, proxy support, you name it.

It is easy to implement a protocol that works with directly connected
sockets. But it gets more and more complex as you add support for SSL,
proxies, proxy authentication, etc.

> > Currently we are forced to use predefined protocols (known by
> > libcurl). If you want something non-standard, you should either
> > implement it yourself from scratch (using sockets), or modify
> > libcurl.
>
> Well, there are also other libraries such as Apache's APR etc that
> should provide a pretty good base to build on.

Or sockets, yes? :)
The reason I am writing this is simple: custom protocols do not come
alone; usually they are an integral part of a bigger bundle.

> The internal telnet support is what presumably should be used for
that,
> if only it was good enough for it. In reality I guess it is closer to
being
> entirely cut out simply because it is in a state where it is hardly
> useful so not many people can use it, and since it is this bad and yet
> nobody feels obliged to fix it it is a proof that not that many people
care
> for telnet support...

I would argue that it's rather a proof that few people could make sense
of how it is implemented in libcurl, and you can't fix something that
you don't understand. :)

> How come you selected to base your telnet attempts on libcurl? (I'm
> trying to be open, to learn and to listen without judging too hard.)

Telnet is universal protocol that can be used for many purposes (e.g.,
for getting emails from a POP3 or IMAP server). So I chose to give it a
try.

I still believe that using an abstract interface for sending/receiving
data is much more convenient and flexible than
a) fighting with sockets, or
b) devising a callbacks-driven state machine.

So, could such interface be possibly implemented? Please. :)
Received on 2008-04-25