Possible issues

[mmalecki]

According to our conversation on Twitter, these are possible issues (don't take all of them seriously, I'm a pedantic guy):

• I'm not really sure about whole this layout. How about having things like this:
  • session.c and session.h with functions it has now + definition of http_session_s (in header - now it's inaccessible for external code),
  • message.c and message.h with http_message_s, http_error_codes and functions like http_message_set_header, http_request and http_response (and optionally parse-related function - I'm not sure if they fit right into session.c),
  • no http.h or http.h which would only include session.h and message.h,
  • possibly another pair of files (like stream.{h,c}) with those stream handling routines.
• we should think about caching those sessions and keeping them alive.

This is how I would do it, but it's your project and everything is up to you. Of course I will be very glad to help.
Also, please ping me here or on Twitter if I'm being unclear or something (I've temporarily monkey-patched my sleep routine to call drink_coffee routine instead ;) ).

[joshthecoder]

I would prefer keeping all public API's in http.h and only require the end developer to include that one header.
We can create additional private headers (ex: session.h) to allow internal communication between the modules.

Sessions will remain alive as long as the end developer keeps them open or the server instructs us
the connection is closing. I may consider adding a session pools in the future to make this a bit more manageable.

[mmalecki]

OK, that's a good idea. I think that easiest way of doing this would be to make http.h include all our .h files.
How about rest of this? Do you like the idea of splitting whole project into 3 files (session.c, message.c and possibly stream.c)?
We should also figure out how http_message_s should look. My proposal is:

struct http_header_s {
  struct http_header_s *next, *previous;
  char *name, *value;
}

struct http_headers_s {
  struct http_header_s *first, *last;
}

struct http_message_s {
  char *method, *uri, *reason_phrase;
  int status;
  struct http_headers_s* headers;
}

Doubly linked list seems most optimal here.

[joshthecoder]

For headers using a hash table with values being linked lists for each header value may be the most optimal way.
More benchmarking and experimentation is required to determine our final solution.