* AUTHORS: Update this to reflect the last 2 years.
* NEWS: Brief summary of 1.99.x -> 2.2 changes
* README, TODO: Updates
SOUP Authors
============
-Alex Graveley <alex@ximian.com>
-Dick Porter <dick@ximian.com>
-Miguel De Icaza <miguel@ximian.com>
+Original SOUP 0.0 - 0.7:
+ Alex Graveley
+ Dick Porter
+ Miguel De Icaza
+
+libsoup 1.99.x - 2.2:
+ Joe Shaw
+ Dan Winship
2004-08-26 Dan Winship <danw@novell.com>
+ * AUTHORS: Update this to reflect the last 2 years.
+
+ * NEWS: Brief summary of 1.99.x -> 2.2 changes
+
+ * README, TODO: Updates
+
+2004-08-26 Dan Winship <danw@novell.com>
+
* libsoup/*: add/fix lots of gtk-doc comments
* libsoup/soup-misc.c (soup_str_case_hash, soup_str_case_equal):
-Joe Shaw <joe@ximian.com>
-Dan Winship <danw@ximian.com>
+Joe Shaw <joeshaw@novell.com>
+Dan Winship <danw@novell.com>
+Changes in libsoup from the 2.0 series (1.99.x versions) to 2.2:
+
+ * Most of the libsoup datatypes are now GObjects. (SoupUri
+ is currently an exception to this.)
+
+ * SoupMessage now emits signals at various stages of
+ processing. (Eg, "wrote_body", "got_headers".) (You
+ can also still use soup_message_add_*handler().)
+
+ * SoupContexts are gone; soup_message_new() now takes a URI
+ string.
+
+ * All formerly global state is now maintained by the
+ SoupSession object. (This includes the connection pool,
+ proxy server, cached authentication information, SSL
+ certificates, etc.)
+
+ * You can create a SoupSessionAsync (for 2.0-like
+ behavior) or SoupSessionSync (for blocking,
+ synchronous usage).
+
+ * You can add SoupMessageFilter objects to a session
+ to have certain processing automatically performed
+ on every message sent via that session. (Eg, setting
+ up handlers.)
+
+ * NTLM authentication is no longer supported by
+ default. You must enable it by setting the
+ SOUP_SESSION_USE_NTLM flag on the session.
+
+ * The preferred method of handling authentication is
+ now via the "authenticate" and "reauthenticate"
+ signals on SoupSession. (The old style, of encoding
+ the user and password information into the url is
+ also still supported.)
+
+ * The SOUP_ERROR_* values are now SOUP_STATUS_* (so that we
+ don't have "SOUP_ERROR_OK" and the like).
+
+ * SOUP_MESSAGE_IS_ERROR() is gone, since some cases
+ want to include 3xx responses and some don't.
+
+ * SOUP_ERROR_CANT_AUTHENTICATE and
+ SOUP_ERROR_CANT_AUTHENTICATE_PROXY are now gone,
+ since they didn't carry any information that
+ SOUP_STATUS_UNAUTHORIZED and
+ SOUP_STATUS_PROXY_UNAUTHORIZED don't.
+
+ * DNS errors now show up as the new status code
+ SOUP_STATUS_CANT_RESOLVE rather than being mixed in
+ with SOUP_ERROR_CANT_CONNECT.
+
+ * Minimal SOAP support has been added back, via
+ SoupSoapMessage/SoupSoapResponse
+
+ * The HTTP I/O state machine was completely rewritten, fixing
+ numerous crashes, leaks, and protocol errors.
+
+ * SoupUri now conforms to RFC 2396. Mostly.
+
+ * Various test programs have been added under tests/
+
+ * Removed:
+
+ * Support for OpenSSL (which was horribly buggy) and
+ Mozilla NSS (which was never finished). We only
+ support GNUTLS for SSL now.
+
+ * SOCKS support
+
+ * CGI support in SoupServer
Soup is an HTTP library implementation in C. It was originally part of
-a SOAP (Simple Object Access Protocol) implementation, but most of the
-SOAP code has since been removed.
+a SOAP (Simple Object Access Protocol) implementation, but the SOAP
+code was later removed (and then later partially reimplemented...)
-Soup uses the Glib main loop and is designed to work well with GTK
-applications. This enables GNOME applications to access HTTP servers
-on the network in a completely asynchronous fashion, very similar to
-the Gtk+ programming model (a synchronous operation mode is also
-supported for those who want it).
+Soup uses GObjects and the glib main loop, and is designed to work
+well with Gtk/GNOME applications. This enables GNOME applications to
+access HTTP servers on the network in a completely asynchronous
+fashion, very similar to the Gtk+ programming model (a synchronous
+operation mode is also supported for those who want it).
Soup also contains code to implement an HTTP/1.1 server.
* Client support for Digest, NTLM, and Basic authentication
* Server support for Digest and Basic authentication
+See the test programs in tests/ for simple examples of how to use the
+code, or evolution-data-server and evolution-exchange for more
+complicated examples.
+
+
To subscribe to the Soup discussion list, send mail with the word
"Subscribe" in the message body to soup-list-request@ximian.com.
+Known bugs/warts to fix
+-----------------------
+* 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
+
+
HTTP Features
-------------
* Pipelining
-* Add qop="auth-int" support to digest auth (both client and server)
-* Handle trailers in chunked responses
+SOAP/XML-RPC Features
+---------------------
+
+* Add XML-RPC support (bug-buddy wants this)
+
+* Bring back WSDL compiler from old soup module?
+
+* The current SoupSoapMessage/Response 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
+ g_string_appending...
Misc Features
* Bring back CGI server support? (Split SoupServer into SoupServerTCP
and SoupServerCGI)
-* Bring back WSDL compiler from old soup module?
-
-* Use gconf for config data (especially proxy info)
+* Use gconf for config data
+ * automatically pick up GNOME-wide proxy settings
* rcd doesn't want more dependencies, so make this optional
-----------------
* Thread safety
- * This is at least minimally done, but need to figure out
- what other things need to be thread-safe, and document
- which ones aren't.
+ * This is at mostly done, but need to figure out what other
+ things need to be thread-safe, and document which ones
+ aren't.
* Documentation (API, tutorial)
+ * gtk-doc is not currently picking up all of the objects.
+ This probably has something to do with the fact that
+ some of the typdefs are in soup-types.h.
* User-Agent handling: caller should specify a User-Agent string to
SoupSession, and soup should automatically append libsoup/#.## to
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
+ * needed if we wanted to do a soup-based gnome-vfs http
+ backend
* Explicit support for Range header
* 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 for consistency.)
+ 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).
-* Add date-parsing/generating routines (all formats)
-
-* Special handling on server side for HEAD (ignore response.body).
+* Add date-parsing/generating routines (all HTTP-specified formats)
-* Make it possible to send/receive "OPTIONS * HTTP/1.1" (SoupURL won't
- accept "*")
-
-* 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
+
Testing
-------
* MUST observe DNS TTL information
+* Make it possible to send/receive "OPTIONS * HTTP/1.1" (SoupURI won't
+ currently accept "*")
+
* [get SHOULDs and SHOULD NOTs in]