Jim's Depository

this code is not yet written
 
Added the maximum concurrent connection support. It took -3 lines of code. sem_init(), sem_post(), sem_wait() is nicer for this than using pthread mutexes on variables.
Well that wasn't half hard. wc reports 279 lines of code weighing in at 7.5kb source and just under 4k of binary for an HTTP/1.0 and HTTP/1.1 compliant httpd function. (Well, still a few more lines to enforce a maximum concurrent thread limit and a thread timeout so I needn't fear nefarious people… but it is nearly done.)

I thought going in that getting HTTP/1.1 pipelining right was going to be the trickiest part, but on further investigation none of the major browsers use it. Apparently enough web servers screw it up to prevent it.

In the absence of pipelining I decided to forgo keep-alive entirely in favor of simplicity. By careful use of TCP options I only need 3 outgoing packets for each request (up to 1.mumble kbytes). The SYN-ACK, an ACK-Data-FIN, and a FIN-ACK.

An interesting performance issue: Safari shotguns me with many simultaneous connections, to which my httpd responds quickly. If I were supporting keep-alive I think Safari would be encouraged to only use two connections and serialize the requests over them. I wonder which is faster? I may have to add keep-alive support just to answer this question.

Another interesting tidbit: Some people on the web maintain that TCP_QUICKACK and TCP_DEFER_ACCEPT are inherited from the listener socket to the accepted socket. I don't think so. At least the only way I can get QUICKACK turned off is to not use TCP_DEFER_ACCEPT on the listening socket  and slam TCP_QUICKACK off on the accepted socket before the first data arrives. Otherwise I end up sending an ACK before my first data packet.

And a last tidbit: You can keep your TCP_CORK in all the to shutdown(), that gets your FIN piggybacked on your last data packet.

Why are there so many packages ruined by people using autoconfigure and libtool? Just write a simple Makefile and let it be. 

The application where I was going to use libmicrohttpd requires me to crosscompile and after hours of thrashing about I still can't get it to build.

Back to the bit heap with it. I'll write my own httpd code.

I can't help but wonder though, can it be simpler? I'll probably have to read the HTTP 1.1 spec and see how simple a daemon I can write.
Went to do the CSS alterations for iPhones. Elapsed time: 0 seconds. Just worked.
You still can't post comments or articles from IE7. I'll tackle that tomorrow.

Things fixed so far:
  1. IE does not have contentDocument, use contentWindow instead.
  2. addEventListenter/attachEvent silliness.
  3. The focus and blur events go on the IFRAME's contentWindow, except Firefox needs it on the contentWindow.document. (Not an IE problem, but my first IE fix broke this.)
  4. The absolute DIV needed an explicit .style.left as it was positioning to the right of the parent.
  5. Odd problem where a delete n.moseyTimer was leaving the value there. I had to set it to false explicitly.
  6. Lucky break: accidentally found a problem with which document I use to make the .selection() call while wresting the fleeing tool bar.
  7. Wash me. Unable to keep the toolbar from taking focus, I have resorted to a timer to notice if a toolbar hide is a result of the toolbar being clicked and suppressing the hide.
  8. IE is still doing amusing things with the spaces around selections when it wraps them. More hackery to come.
Ok, comments seem to be at least minimally functional with the new editor code in Safari.
  1. Switch new post editing over to the new style.
  2. Make sure I didn't break Firefox.
  3. Patch things up so IE works.
  4. Make a safe fallback to HTML for browsers without designMode.

Well don't I feel silly. I have written 700 lines of beautiful Javascript that implements WYSIWYG editing. I deal with ranges and selections, I have elegant recursive tree rewriting functions to handle deletions, even if it is the left half of a LI back to something before the enclosing UL… yeah, that is tricky… and much more… But I can't copy and paste. The browser won't enable the paste menu item for my item.

When suddenly…

In the process of trying to see how tinyMCE got paste to work, and also realizing that I couldn't find the code they used to move the cursor in response to an arrow key I discovered contentEditable and its buddy designMode which Firefox will require. This is now a much easier problem. I will throw away all my beautiful code and just make a handful of API calls.

And just when I thought there was still a reason for giants to roam the earth.

Darn it. Now I'm going to have to implement some sort of attachments. I'd like to give you this code, but I don't want it enlarging the front page.
Comments and articles also get a preview button now so you can see what they will look like before you post them. Not too critical since you can edit them afterwards, but I suppose people are conditioned that think they can't edit comments.
more comments