gaal, who might have to use it someday!) and for whoever else cares.The old network code used to be a big jumble, in part because it was the combination of a few different things in one interdependent pile of functions:
- the code to use curl
- the code to handle communication through the fork
- the GUI for network progress
- the high-level network-request functions
Redesigning things to work on Windows simultaneously required me to reevaluate all that and I think the result is cleaner. It now looks like this:
- network-platform.c (currently) provides two low-level HTTP interfaces which report progress through callbacks.
- A blocking interface. This actually does the calls into the underlying library.
- A "mainloop" interface. (This one is two functions-- one to start, and another to cancel one in progress.) The mainloop interface starts the blocking request in another process/thread and starts a GTK/glib mainloop, which means that if you (for example) had a network status window up when you called the function, it would continue updating.
- network.c provides the higher-level interface used through LogJam, in which you give it a NetRequest hash and it returns a NetResult hash. It handles all the GUI and serializing/deserializing these hashes for use in HTTP requests by the lower layer.
Why is this important? Well, aside from things working on Windows, now, there are a bunch of places we've needed finer control over the network requests. For example, we're now able to do things like pull a person's userpics (which will use the HTTP functions with a different GUI and not the higher-level LiveJournal-request-oriented functions) and download a person's journal (which will be a series of LiveJournal-requests that need a different GUI as well).
In case you haven't guessed, I got mono and I've been stuck inside for a week. :)
