Balau - Unnamed repository; edit this file 'description' to name the repository.

Age	Commit message (Collapse)	Author
2011-11-18	Starting to re-organize the HTTP code a bit. Sharing code between the server ↵	Pixel
	and a potential client makes sense. Also packing requests and responses into structures / classes is probably a good idea.
2011-11-18	Updating libev's timestamp after we (potentially) wait a long time for ↵	Pixel
	something to do.
2011-11-17	Adding a few reasons why we'd get an HTTP 400 error, and fixing the ↵	Pixel
	Connection header (I hate RFCs, they never mentionned keep-alive in the list of potential headers)
2011-11-17	Look at that. It seems that, indeed, IPv6 CAN get very retarded.	Pixel

2011-11-17	HTTP server's first real test, alongside multiple taskmanager threads.	Pixel
	I'm not really sure I fully like the way I'm designing this, but I guess it could be solved with an HTTP/HTML helper class around the Action class. However, the HTTP server awfully need reference counting, so it doesn't go away before all of the workers disappear, which means a bit of a redesign of the Listener template.
2011-11-17	Forgot to remove this; we shouldn't free the stack from the Task itself ↵	Pixel
	anymore: the task manager takes care of this now.
2011-11-17	And adding the round robin system to the task scheduler. Now to write some ↵	Pixel
	unit test for this...
2011-11-17	Cleaning some code, redesigning a bit the stack allocation problem from the ↵	Pixel
	task manager, and actually implementing it properly.
2011-11-17	Introducing the fact we need a more efficient stack allocator, and that it's ↵	Pixel
	to be performed from the task manager.
2011-11-17	Since tasks can be on different task managers, one has to signal them a bit ↵	Pixel
	differently.
2011-11-16	Adding the Regex class.	Pixel

2011-11-16	clang actually managed to pick up a bug...	Pixel

2011-11-16	And with the new TaskScheduler system, let's add a way for a new task to ↵	Pixel
	stick on another one's thread, if needed. (and it is)
2011-11-16	Kind of a big revamp of the TaskMan / Task model, in order to introduce a ↵	Pixel
	TaskScheduler. The idea is that we need to support multiple task managers from multiple threads. So that revamp means we now should be able to support that, except the TaskScheduler needs to implement a round robin system, to distribute tasks across multiple task managers. But at least, the fundamental redesign to permit this is here.
2011-11-16	Even if an URI doesn't have variables embedded, it still may contained ↵	Pixel
	escaped characters.
2011-11-16	Adding a simple 'daemon name' for our output.	Pixel

2011-11-16	Using the new WriteOnly class in the HttpServer, to protect the socket from ↵	Pixel
	being read, as it needs to go thru the BStream.
2011-11-15	Basic POST support done; multipart/form-data is yet to be finalized.	Pixel

2011-11-15	A bit more work on the HTTP server. Only the parsing of the POST method is ↵	Pixel
	remaining. Multipart is going to be cumbersome.
2011-11-15	The HTTP server now takes advantage of that new parameter of forceRead/Write.	Pixel

2011-11-15	Adding a potential event to cancel a forced read/write, such as a timeout.	Pixel

2011-11-15	Balancing code a bit out of the constructor.	Pixel

2011-11-15	Actually, that's the proper fix for the Listener system, otherwise accept() ↵	Pixel
	will never stop, rendering the stop method of the Listener inneffective.
2011-11-15	Moving code around for the Listener, in order to avoid too much template code.	Pixel

2011-11-15	Adding the forceRead/Write methods, to circumvent the potential problem that ↵	Pixel
	a file descriptor can do less than being asked.
2011-11-15	Moving the static yield from Task.h to Task.cc. You don't want to throw an ↵	Pixel
	exception from a .h file...
2011-11-15	Fixing the Socket code a bit, effectively making the listener system working.	Pixel

2011-11-15	Fixing a few parsing mistakes.	Pixel

2011-11-15	Initial parsing of the Http request should now be there.	Pixel

2011-11-14	Typo.	Pixel

2011-11-14	Some more basic work on the HTTP server. Some of the main ideas are not ↵	Pixel
	fleshed up, and writing the actual server should now be sort of straightforward.
2011-11-14	Funny this worked so far; fixing accept().	Pixel

2011-11-14	Making the ResolverThread exitting properly.	Pixel

2011-11-13	Adding the skeleton of an HTTP server; still work in progress though: it ↵	Pixel
	still needs coding, and won't work as it. And it needs a unit test.
2011-11-13	Adding buffered streams; mainly for string parsing.	Pixel

2011-11-13	Fixing a few bugs with Buffer - yes, it indeed does need a few more unit ↵	Pixel
	tests....
2011-11-13	Adding isEOF() to Buffers (and cleaning code a tiny bit)	Pixel

2011-11-13	Securing double closes in Sockets.	Pixel

2011-11-12	Adding seekable buffers. Probably would need a few more tests in the Handles ↵	Pixel
	unit test.
2011-11-10	Fixing that heisenbug. Huh, yeah, it's usually better to use a real TLS ↵	Pixel
	instead of a dummy one...
2011-11-10	... didn't I already fix this one... ? Weird.	Pixel

2011-11-09	Securing a bit more the thread-joining.	Pixel

2011-11-09	Adding 'Output' object	Pixel

2011-10-26	Adding Lua.	Pixel

2011-10-26	Protecting the IO class a bit more, and adding the raw filename paradigm for ↵	Pixel
	at least the Input class.
2011-10-25	Adding the FileSystem global class with mkdir, and adding the writeString ↵	Pixel
	method to Handles. Also preparing the inclusion of Lua by adding LuaJIT.
2011-10-18	libcoro seems to be doing really spurious things when not using the standard ↵	Pixel
	functions. Switching out libcoro for the native Fibers interface for Win32. Switching out the asm version for the ucontext version for Linux.
2011-10-18	Adding a few more asserts, and using the proper function calls (ntohs ↵	Pixel
	instead of htons - which should be fundamentally the same, but, shrug)
2011-10-18	Why is Win32 so not Posix ... ?	Pixel

2011-10-18	Fixing Darwin compilation:	Pixel
	-) Using clang instead of gcc for the native target (sigh) -) Fixing libeio (sigh) -) "Fixing" the connect() call in Sockets because Darwin is stupid (SIIIIIIIGH) Although the Threads unit test isn't working properly.