We've discussed it a lot.
I actually wrote one, then removed it.

The problem is that a library wouldn't add much.

HTTP should be done by a real HTTP library, which is platform-specific (Mac OSX and Win32 have them as part of the OS, KDE has its way and GTK people use external libraries).

Request information should be returned as a hash, but C has no fundamental hash type.

You could break down every response into structs, but that's more work and it doesn't get you anything.
Instead of
hash_table_lookup(response, "year");
it'd be
response.year
and you'd still need to look up that it's "year" and not "date" or something.

Yep. I dealt with this question too, and came to the same conclusion.

The protocol currently is just too simple for a generic library to be useful.

This could change, though I rather would it didn't ;)

Why not write it in c++ and use an stl map?

And I don't know too much about HTTP, so I may be wrontg, but it seems like HTTP is simple enough that it wouldn't be a major sin to just implement the subset that livejournal requires rather than re-use existing libraries for the sake of portability...

Just a couple thoughts...

The protocol doesn't seem too complicated, superficially, but it's pretty easy to have problems.

Consider:
- proxies (each os has different ways of specifying your proxy server)
- line endings (some clients were just sending \n, which worked until we got the bigip and then suddenly clients stopped working)
- new features (we now need to send a fastserver cookie; not too hard to implement, but something worse could happen later)
- weird situations (mangled responses from the server could cause a crash, which in this case means a lost post)
- blocking issues (do you use threads? select()?)

Argh, another lost post, #$$^&%#!

:)

My 2 cents.. I agree, the protocol is simple enough. Looking at it from a KDE perspective, it is just a little bit of glue work between the application and the HTTP library. If it were more complex, that would be different. And, for example, for KJournal, it will be implemented in C++, while LogJam uses C, and the two are pretty exclusive, despite being the same language. While the C code COULD be used for both, it would not be considered good C++ code.

As I recall, KDE has a really cool HTTP library, too. :)

Yeah, it does. And the best part is, the HTML stuff is not an external program. Konqueror is, for the most part, just an implementation of the KHTML class. So one of the features I have planned is the web links opening the view right inside the client window. I was looking over a KDE tutorial, and one of the programs was a fully featured web browser, including all features of Konqueror (Netscape plugins, javascript, cookies, etc) in under 100 lines of code.

Also, it has HTML text display classes, so having a entry preview is not that far fetched.

I argued that HTTP was simple enough when Evan used libcurl in LogJam. A few weeks later, mIRC-LJ broke because my HTTP handler sucked. I don't disagree anymore! ;)

(Not that there's a proper HTTP library for mIRCscript, of course... my handler still sucks, it just sucks less now.)

I started working on this lib idea on my own. I'm working on a plain C version as well as on a C++ and a Java package. I think, I'll publish the first versions of them in about 4 weeks. As I have to do a lot of college work, too, I am not able to work on it as constantly as I would like to.