Google Summer of Code
We applied up to become a mentoring organization for Google Summer of Code 2008, and on this page we collected ideas that could serve as starting points when students want to write up a project idea for curl!
However, we were not lucky enough to be one of the selected organizations when Google announced the accepted ones on March 17 2008. The not accepted status is without motivation so we can only guess why this happened: too small/informal organization? Too crappy ideas page? Too few existing mentors listed? I don't think the actual application form was bad since it was very similar to the one I used for another project that was accepted...
- SMTP - although it isn't really yet determined that this would truly be a good addition. Prepare to explain to use why it is!
- data: URLs (mostly a case of completeness for applications that use libcurl for all URLs)
- RTSP is for streaming data
- MMS:// streams. A Microsoft protocol for streaming content. See the existing mms client source code for inspiration and start.
- RTMP A patch for parts of this is mentioned here
Improving existing stuff
- native (i.e.: library-less) LDAP(S)
- Preparing for fips accreditation (using openssl fips)
- Complete Java integration/binding
- Fix the last remaining blocking calls within libcurl
- Fixing up lacking language bindings
- make the curl tool use the multi interface and allow it to do parallel transfers
- Test suite improvements: adding support for more protocols. Most notably perhaps FTPS, telnet and ldap(s). Make a "native" stunnel version that works with the selected SSL library of choice.
Provide New Functionality
- HTTP Caching
This isn't as simple a problem as it might seem as there are potential issues with security and also because depending on use cases, you will want to store the cache in different places with different sizes...
Or rather, a "caching framework" which allows the user to define callbacks for actually storing the data in a filesystem, database, or whatever he prefers.
Some aspects of the HTTP standard are not well-known and people are bound to get them wrong if they implement caching themselves, e.g. the "Vary" and "Etag" headers.
- Non-blocking third party FTP transfers. libcurl did previously support third party FTP transfers (sometimes called FXP), but not in non-blocking manner and the code wasn't maintained properly so support was dropped.
These guys are volunteering to mentor students:
To become a mentor, you need to sign up for an account to google if curl gets accepted.