Daniel Stenberg wrote:

> So, as we change/add a major API we could just as well re-evaluate how we do
> things today to see if we could do them better tomorrow. What features are
> missing? What blue-sky visions do you have that's been dismissed from your
> mind or by me (eh, well I *know* I dismiss people and ideas at times, I'm not
> always mankind's best friend)? LDAP and DICT support should also be
> re-considered if they are to remain in libcurl or not. Hardly anyone uses
> them (AFAIK).

Don't know what 'DICT' does, I don't use it, but I would like to use the
LDAP support - just haven't got a round to it yet (I'm using perl
Net::ldap, but good curl support might be better). Improvements would be
figuring out the correct openldap .so to load at build time (rather than
hope for the best at run-time) and better parseable output from ldap
urls (I don't know if this is curls' fault). I guess you should be able
to update ldap entries through curl ldap urls, but I haven't even dared
consider how to do that...

Wishlist:

* Async DNS and/or DNS caching - w3clib does some fancy caching of dns
results and weights and round-robins according to selectable external
policy. Quite nice I think.

* Shareable connection pool - libcurls' connection cache could be shared
by multiple libcurl-using processes if there was some external api for
searching a pool, loading or unloading the connection state and adding,
fetching and removing an FD. I'm not saying curl should do this, but if
the library had this API, then some hypothetical connection manager
could keep a central pool, and libcurl could do a callback to see if a
connection was in a shared cache, and request to be passed the
descriptor. Needs to work with SSL connection state too. FD pushing
through local sockets is not extremely portable, but if its just an API,
thats not libcurls problem. Certainly usable by phpcurl and others
(including me)...

(See the apache 'parental accept patch' for an example of this working
well on the server side of a connection pool
http://www.cnds.jhu.edu/~jesus/projects/parental_accept.patch )

* NTLM authentication & proxy authentication
Nice for thos stuck behind inflexible, non-standards MS-Poxy servers and
needing to connect to intranet servers outsied their control. Can't just
lift the samba code, due to incompatible licencing, but the protocol
description is freely available, and I've seen free python code do this
already. Good connection pooling would cut down the processing overhead
of this ridiculous protocol violiation...

* SSL Engine support
Now Götz has raised it, yeah, sure - I'd love engine support. Don't
have a hardware engine yet, but openssh have smartcard client certs
going through this mechanism already I believe...

> Open your mind and show us what pops out.

Messy - rather not.

> I previously thought that I'd be able to get a very early multi-interface
> implementaion ready for a rough preview before christmas, but I now realize
> that I won't be able to meet that schedule. To prevent me from having to push
> more dates, I'll just refrain from mention a date at the moment and just say
> that I hope to get a rough preview ready as soon as possible, but it won't
> happen in 2001.

I haven't followed the 'multi' discussion in detail, but as long as I
can plug in an external event loop I think it would be fine.

Cris
Received on 2001-12-13