sync to text on wiki, and point to wiki

	* README: sync to text on wiki, and point to wiki

	* TODO: moved to http://live.gnome.org/LibSoup_2fToDo

1 files changed, 0 insertions, 163 deletions

diff --git a/TODO b/TODO
deleted file mode 100644
index 3ceebee5..00000000
--- a/TODO
+++ /dev/null
@@ -1,163 +0,0 @@
-Known bugs/FIXMEs
------------------
-
-* Needs to be possible to register new auth types with soup-auth.c
-
-* SoupAuthDigest/SoupServerAuthDigest don't support qop="auth-int"
-
-* We don't handle trailers in chunked responses
-
-* Expect: 100-continue processing doesn't currently abort sending
-  the body if it gets back a non-informational status code
-
-* SoupConnections never time themselves out. They always wait for the
-  server to time them out (and even then they don't time out until you
-  try to use them again).
-	* NTLM connections should stay open longer than plain ones
-
-* SoupSessions tend to get leaked because of circular refs (each
-  connection refs its session as a SoupMessageFilter)
-
-* URI encoding bugs
-	* query component at least, maybe others must be stored
-	  fully-escaped, because only the endpoints know which
-	  chars are and aren't reserved
-	* When fixing this, also consider:
-		* Merging E2kUri with SoupUri
-		* application/x-www-form-urlencoded, which encodes
-		  space as "+" rather than "%20"
-		* SoupUri doesn't currently allow "*" as a URI
-
-* soup_session_queue_message() does nothing on SoupSessionSync.
-
-* soup_xmlrpc_value_get_base64() returns the encoded value, not the
-  decoded value.
-
-* The synchronous SoupSocket API is slightly broken. This is mostly
-  not a problem for the HTTP engine, but it's obvious in
-  tests/revserver.c that the stack will eventually overflow. The fix
-  is to have SoupSocket return WOULD_BLOCK when changing direction,
-  and require the caller to unroll the stack back to the top level in
-  that case before trying again.
-
-
-HTTP Features
--------------
-
-* Handle gzip Content-Encoding
-
-* Handle cookies (RFC 2109) via a SoupCookieJar message filter
-	* libexchange has some minimal cookie functionality for
-	  Exchange 2003 forms-based auth
-	* RFC 2965 supposedly obsoletes 2109, but I don't think
-	  anyone uses it. (Yeah, grep for "cookie" here:
-	  http://www.nextthing.org/archives/2005/08/07/fun-with-http-headers)
-
-* Handle caching, also via SoupMessageFilter
-	* rcd has some of the logic for this already
-
-* NTLM Proxy-Authentication support, GSS-Negotiate support
-
-* Pipelining
-
-
-SOAP/XML-RPC Features
----------------------
-
-* Bring back WSDL compiler from old soup module?
-
-* The current SOAP/XMLRPC API doesn't really make life a whole lot
-  easier for the user... You have to marshall the data in exactly the
-  right order anyway, so you might as well just be using
-  g_string_append...
-
-
-Misc Features
--------------
-
-* Bring back SOCKS support?
-
-* Bring back CGI server support? (Split SoupServer into SoupServerTCP
-  and SoupServerCGI)
-
-* Use gconf for config data
-	* automatically pick up GNOME-wide proxy settings, including
-	  ignore_hosts, etc
-
-
-General/API stuff
------------------
-
-* Documentation (tutorial, hacking, thread safety)
-
-* User-Agent handling: caller should specify a User-Agent string to
-  SoupSession, and soup should automatically append libsoup/#.## to
-  that. (Likewise for Server/Via headers.)
-
-* File-system-like asynchronous mode (eg, you write the request / read
-  the response in as many pieces as you want. If you try to read or
-  write more than you can, the EAGAIN is returned all they way to the
-  caller, who must call the relevant soup function again later to
-  continue reading or writing).
-	   * needed if we wanted to do a soup-based gnome-vfs http
-             backend
-
-* Explicit support for Range header
-
-* Merge SoupAuth and SoupServerAuth
-
-* Merge SoupMessage and SoupServerMessage (allow chunked requests)
-
-* Improve SoupServer handlers to allow for expect-continue handling,
-  reading chunked requests a chunk at a time, etc.
-	* Use SoupMessageFilter
-	* Improving SoupServer's API will probably result in
-	  completely breaking it.
-
-* SoupProxy (based on simple-proxy, but better), which connects a
-  SoupServer to a SoupSession with SoupMessageFilters in between.
-	* Make it possible to implement CONNECT on the server side (by
-	  having a way to steal the socket from the SoupServer).
-
-* Special handling on server side for HEAD (don't send response.body).
-
-* Simple higher-level API (a la E2kContext)
-	* the Connector stuff has a lot of Exchange-specific
-	  assumptions and exceptions. Might not be possible to
-	  migrate Connector to a generic API
-	* jamesh's HttpResource object
-
-
-Testing
--------
-
-* More regression tests
-
-* Add apache config files to tests/ so that apache can be run locally
-  to run regression tests against
-
-
-Conformance
------------
-
-* Check handling of unknown HTTP versions [RFC ????]
-
-* Don't do HTTP/1.1-specific behavior on HTTP/1.0 messages
-
-* Preserve header ordering (on send and receive). Treat
-  "Foo:bar\r\nFoo:baz" the same as "Foo: bar, baz"
-
-* Enforce rules about what requests/responses MUST/MUST NOT have a
-  body
-
-* Don't automatically process redirects on non-GET/HEAD requests
-
-* Properly mangle HTTP/1.0 requests containing Connection headers
-  [14.10]
-
-* Automatically add Date header in SoupServer
-
-* MUST observe DNS TTL information
-
-* [get SHOULDs and SHOULD NOTs in]
-