more thoughts on stuff to change in 3.0
-
Drop old session/message APIs and associated I/O paths
ie,
soup_session_queue_message
,soup_session_requeue_message
(*),soup_session_send_message
,soup_session_pause_message
,soup_session_unpause_message
,soup_session_cancel_message
,SoupMessage::got-chunk
,SoupMessage::wrote-chunk
,SoupMessage::wrote-body-data
, maybe moreThe original soup I/O system where it does the I/O for you and emits signals. Also includes getting rid of the pre-
GCancellable
cancellation system which is weird and inconsistent. As a free bonus, this will render half oftests/
irrelevant, because they are just testing all the crazy weird edge cases of the old API.soup_session_requeue_message
is probably currently used even by the newer APIs so it needs to be decoupled from the old APIs.Tricky part: to actually get rid of the old
soup-message-io.c
codepaths, you need to also get rid of the corresponding APIs inSoupServer
, except that there aren't currently any "new" APIs inSoupServer
(that's #67). -
Drop
SoupSocket
, move the complicated parts up intoSoupConnection
orSoupServer
, replace the simpler with directGSocket
/GSocketClient
/GSocketListener
usage in the callers. -
Possibly drop
SoupConnection
or at least make it not an object... it has become increasingly vestigial over time. (I'm not sure about this one; this might not make sense.) -
See how much of
soup-date.c
can be deprecated. It predatesGDateTime
and is probably mostly unnecessary now. The parsing code is necessary to deal with cookie date-parsing horribleness, but it could return aGDateTime
instead. I don't think it should be necessary to expose any libsoup-specific date/time functions.Tricky part: XMLRPC has a concept of floating times, whereas a
GDateTime
always has a time zone. There could be hacks. Besides, does anyone even use XMLRPC any more? -
Replace
SoupBuffer
withGBytes
. IIRC, the optimization provided bySOUP_MEMORY_TEMPORARY
got subverted at some point because we end up always having to copy the data anyway (because of a signal emission?) so it could just be replace withSOUP_MEMORY_COPY
, and then at that point all ofSoupBuffer
could just be done withGBytes
. -
Drop
SoupURI
, useGUri
and some helper functions -
Rewrite
SoupSession
connection/host/queue management from scratch. Actually think about thread-safety from the beginning this time. Consider having separateSoupMessageQueue
s; one for synchronous messages, and one for each separateGMainContext
currently in use. Of course the HTTP/2 plans will also affect this part. -
Simplify
soup_headers_parse_{,semi_}param_list{,_strict}
? -
Simplify
SoupMessageBody
? I have no specific ideas here, but in particular, if the signal-emitting I/O APIs are going away then a lot of this probably doesn't make sense. -
Fix anything pertaining to TLS that is still confusing (
soup_message_get_https_status
?) -
Make
SoupRequest
feel more integrated / less bolted-on-after-the-fact. (eg, maybeSoupRequestHTTP
andSoupMessage
should be the same type?)