Firefox Support

Problem: The Firefox mouse event object does not support the clientX or clientY properties.  ClientX and clientY are fantastic because they give you the position relative to the element.
Solution: Most sites recommend using (event.pageX – elem.offsetLeft) but this gives inaccurate values when the HTML element has auto-margins.  The solution to this problem was to relatively position the canvas element.  Relative positioning doesn’t affect the rendering of the element at all, preserving its position in the document and its flow, but it does reset the coordinate system for event.layerX and event.layerY.  Simply adding this simple CSS allows the code to work for both Firefox and Chrome.

Problem: Firefox failed to render the game pieces.  The gameboard itself was rendered correctly.
Solution: After a bit of debugging, I found that FireFox was rendering correctly until it received a command equivalent to ctx.scale(1,0) when the pieces flip.  This command, while not raising a JavaScript error, effectively crashed the canvas, causing it to not accept any future commands.  Simply wrapping that block of code with an -if- statement got things rendering. The issue was filed with a testcase as bug 661452.

Problem:  Rendered text wasn’t updating.
Solution: FireFox doesn’t support innerText, switched to innerHTML as no markup was included.

Problem: Some gradient backgrounds weren’t rendered.
Solution: Added Mozilla gradient CSS.

IE9 Support

Problem: Values for event.layerX and event.layerY were way off.
Solution: Since Chrome and IE support event.clientX and event.clientY, I ended up using the following code for all three browsers:

 var x = event.offsetX == undefined ? event.layerX : event.offsetX;
 var y = event.offsetY == undefined ? event.layerY : event.offsetY;

Problem: Internet Explorer does not support gradient backgrounds.
Solution: While Internet Explorer doesn’t support gradients, it does support SVG backgrounds.  Creating a SVG file with a gradient and a width and height set to 100% has it fill the box.  Best of all, this solution works with Chrome, IE9 and FF4, meaning we don’t need to use browser specific CSS.

Unsolved Problem: IE9 does not yet support text shadows.  While there are some hacks out there for basic shadows, the iOS style elements use inlaid shadows and there’s no obvious solution.  Fortunately this is a small cosmetic issue.

Unsolved Problem:  IE9 does not yet support web workers.  I could move the AI logic into the main thread for IE, but this would make the browser unresponsive.  In the mean time, a JavaScript exception will raise (not user visible) when you select an AI level but clicking back 0n Human will let you resume single player mode.

iOS Safari Support

Interested in how it would do, I opened the original version in the my wife’s iPad.  The game worked flawlessly, even with the AI.  Of course, the iPad has the same browser engine as Chrome.  There are a couple things I noticed that could stand some improvement:

• Since your fingers don’t really simulate a mousemove event, there is no move previewing.  For this kind of device a two click approach would simulate nicely, with the first click simulating the mouse entering a square and the second confirming the move.
• Clicking on the canvas highlights it briefly.  I haven’t really looked into why but it would be nice to eliminate that graphical problem.
• Testing on a friend’s phone, I noticed that the AI didn’t work, which suggests that the iPhone 4 doesn’t support web workers.  It’s interesting to see two different iDevices released so close together have different feature support.  One correction would be to check for the Worker object before showing the AI selector.
• Testing on the iPhone, I also saw that the game existed in a one inch square on account of the retina display.  The game would benefit from mobile device and resolution detection.

Conclusion

If you didn’t notice, not a single change above was related to the canvas’s rendering.  There was just one related to the context crashing.  The canvas did phenomenally in all three browsers, behaving identically and rendering the exact same results.  Admittedly this isn’t the most complex example, but it does include mouse event driven animation that can respond pretty rapidly.  Given how well the canvas is supported across the different browsers, I would consider using it for more complex applications.

As far as the other aspects of HTML5 go, I was a little sad to see text shadows and web workers not supported in IE9 but was delighted to see the SVG background in action.  Since SVG backgrounds have cross-browser support, I would recommend using them in place of browser specific background gradient CSS.

Features

• Canvas based Reversi board with animated moves.
• Worker based AI that can be interrupted to change the difficulty or disable. (Warning: Anything above easy was incredibly time and CPU intensive on my 4 year old computer.  It may be better with new computers.)
• Goofy iPhone style interface, since the next step would be to turn this into an iPhone app.
• Warning: Only tested with Chrome.  No clue how it will react to other HTML5 compatible browsers.

Thoughts

The canvas interface is pretty easy to work with and reminded me a lot of working with the Cairo graphics library.  It took less than a day to get the actual game up and running, a couple days to get the worker AI running, a few more days rewriting the JavaScript using proper class structures and inheritance, and a few days just messing around with the CSS.  The development tools available in Chrome were invaluable, making it a cinch to debug code, track down performance problems, and quickly identify what CSS was being used by other sites.

Recognition

• http://www.codeproject.com/KB/game/reversi.aspx – I lifted all of the AI code off of this site.  It’s a pretty cool algorithm which simulates all possible moves and uses a weighting system to determine the best one.
• http://leaverou.me/2010/02/iphone-keyboard-with-css3-no-images/ – I lifted some CSS from this CSS3 iPhone keyboard to make my buttons.
• http://jeffbatterton.com/blog/5 – I lifted some CSS from this CSS3 iPhone to make the top part of the screen.
• My darling wife for putting up with my obsession this past couple weeks.

That said, TagLib# is still alive and kicking under the umbrella of the Banshee Project.  It’s just not well publicised.  If you would like to use TagLib# in your next closed or open source project, below are some links that can help.

• Downloads (even Windows still!): http://download.banshee-project.org/taglib-sharp/
• Bug Reporting: https://bugzilla.gnome.org/browse.cgi?product=taglib-sharp
• Source Code Repository: http://anonsvn.mono-project.com/viewvc/trunk/taglib-sharp/

Many thanks to Gabriel Burt for his continued maintenance of the library.

Best regards,
Brian Nickel

THIS WEEK’S ACCOMPLISHMENTS

The last week was a bit sparse on accomplishments. I had a lot of preparation to do to prep for the first week of school, and most problems have been resolved, but the following changes were made:

• Application checking was reworked to verify that Web.Config also exists. As it stands, the application manager checks for both Web.Config and Bin when adding an application. Web.Config doesn’t necessarily mean something is an application, but the lack of it means that it isn’t. (I’ve been told this is a IIS rule.)
• Requests that are directories but don’t end in a slash are redirected to the one with a slash.
• Case insensitive checking is used for “Web.Config”, “Bin”, and index pages to improve compatibility.
• Log levels can be set in the command line.
• Log messages can be sent to the standard output.
• ConfigurationManager.xml has been reorganized to group commands more logically.

WHERE IT STANDS NOW

At this point, the FastCGI Mono Server works completely with Lighttpd and Abyss, and when used with Apache and mod_fcgid, behaves like the default config supplied with mod_mono.

Cherokee has some problems when multiple requests are sent at the same time, but this may be a problem on either end. (In most cases, the mistake has been on my end.)

PLANS FOR THE FUTURE…

src/Mono.WebServer: Much of my work on Mono.WebServer is to be refactored and worked into Mono.WebServer (XSP package). This may mean automatic mapping support in mod_mono as well in the future.

src/Mono.WebServer.FastCgi: Most of the Mono.WebServer.FastCgi stuff will be restructured to and made more generic (think Mono.WebServer.CgiRequestWorker and Mono.WebServer.CgiApplicationHost) which will be reusable for things like SCGI support. This means fastcgi-mono-server may appear in XSP as well.

src/Mono.FastCgi: Support still needs to be finished for the Authorizer and Filter roles, and some renaming/FxCop/Gendarme needs to be applied. In the near future, I recommend bundling it with your application if you’re using it, but in the distant future, I expect it to be API stable/GAC-able.

Unfortunately, I will be taking 19 credit hours this semester, to accelerate my transition from Chemical to Computer Systems Engineering. This means I’ll have much less time to contribute, but I will continue to work on this (and my other) project.

SPECIAL THANKS

Special thanks to Google, the Mono SoC administrators, Marek, Daniel, Dick, Miguel, and everyone who commented or contributed in some way to my project! I appreciate all the support and the opportunity not to totally waste my summer.

Sincerely,
Brian Nickel

PS. Trac seems to have my IP address confused with a spammer, so I can’t report bugs on sites that don’t provide public registration. Does anyone know how I can fix this?

THIS WEEK’S ACCOMPLISHMENTS

The Changelog grew by 116 lines this week. Key features are as outlined.

• “Blocking” property was removed from Mono.FastCgi.Socket. It was only used to disable blocking on a socket that already communicated with asynchronous calls and was causing a problem with Abyss and unmanaged sockets.
• All headers are now sent in a single batch rather than one at a time. This should reduce the amount of network traffic and prevents Nginx from occasionally losing a request.
• Added documentation for Abyss X1 and Nginx.
• Fixed .in files not to hardcode mono location.
• Provide a friendly response 500 error page if no application could be found for a request.
• Added directory root detection with code borrowed from XspWorkerRequest.
• Found bug in Mono.WebServer where MonoWorkerRequest.SendFile was double closing a handle.
• Removed check for file existence when creating applications. This way proper applications can still be created when the user mistypes the path.
• Added documentation index page with important information on using paths vs. extensions, what are ASP.NET applications, how applications are handled, and running fastcgi-mono-server on a different machine than the web server. Plus brief information on how a request is actually processed, from Firefox to ASP.Default_aspx:Render(). See http://mono-soc-2007.googlecode.com/svn/trunk/brian/FastCgi/doc/index.html
• Added svn:eol-style=native to .html and .cs files.
• Added svn:mime-type to HTML and PNG files so they will show up in a web browser.
• Fixed the status line. It was being sent in the HTTP: “HTTP/1.1 200 OK” format instead of the CGI “Status: 200 OK” format. This was causing some breakage where status 200 was always being sent from web servers and Apache wasn’t working at all.
• Better output for “/help”
• Added some docs for using paths instead of directory mapping.
• Cleaned up UnmanagedSocket with proper SocketExceptions and a wait handle for EndAccept.

and

After discussion with Daniel Nauck changed the recommended method of handling ASP.NET to sending all requests to fastcgi-mono-server. The benefits are outlined at http://mono-soc-2007.googlecode.com/svn/trunk/brian/FastCgi/doc/index.html#info1 but in short they are improved security and enhanced features with application specific configuration.

PLANS FOR THE COMING WEEK

1. Continue documenting.
2. Alpha release.
3. Clean up API.
4. Adding open source tools: mailing list, bugzilla, wiki page???

CHALLENGES I’M FACING

Mostly just a million different web server nuances.

RESOURCES USED THIS WEEK

• MSDN: WaitHandle, System.Web.UI.Page, IAsyncResult
• Netcraft: Server statistics.
• Apache API reference: Trying to understand cmd_parms.
• FastCGI.com: Performance statistics.
• CGI specification: Review.
• http://svnbook.red-bean.com: Information on properties.

Sincerely,
Brian Nickel

<IfModule fcgid_module>
 <FilesMatch ".(aspx|asmx|ashx|asax|ascx|soap|rem|axd|cs|config|Config|dll)$>
    SetHandler fcgid-script
    FCGIWrapper /usr/bin/fastcgi-mono-server .aspx
    FCGIWrapper /usr/bin/fastcgi-mono-server .asmx
    FCGIWrapper /usr/bin/fastcgi-mono-server .ashx
    FCGIWrapper /usr/bin/fastcgi-mono-server .asax
    FCGIWrapper /usr/bin/fastcgi-mono-server .ascx
    FCGIWrapper /usr/bin/fastcgi-mono-server .soap
    FCGIWrapper /usr/bin/fastcgi-mono-server .rem
    FCGIWrapper /usr/bin/fastcgi-mono-server .axd
    FCGIWrapper /usr/bin/fastcgi-mono-server .cs
    FCGIWrapper /usr/bin/fastcgi-mono-server .config
    FCGIWrapper /usr/bin/fastcgi-mono-server .Config
    FCGIWrapper /usr/bin/fastcgi-mono-server .dll
    Options +ExecCGI
 </FilesMatch>

 DirectoryIndex index.aspx
 DirectoryIndex Default.aspx
 DirectoryIndex default.aspx
</IfModule>

There are two important shortcomings:

1. Just wrapping extensions is not a recommended way of working with ASP.NET, as it lacks certain security and management features. It is better to just send the whole directory to the Mono server. (More on this, Friday.) As far as I understand it, this will require a change in mod_fcgid.
2. WebResource.axd shows up as a 404 error rather than the expected resource, this can be overcome hackishly by creating an empty WebResource.axd where the other one is expected. Does anyone who knows Apache know how to overcome this?

Sincerely,
Brian Nickel

Important changes that make this possible:

• Status 200 is sent again. Abyss was sending its own status (I presume 404) if the file didn’t exist and fastcgi-mono-server wasn’t sending in information.
• Blocking is no longer set for sockets. It didn’t appear to provide any essential features, as the server uses asynchronous calls anyway, but it was causing the unmanaged socket to stop listening on Abyss.
• Response headers are now stored in a string builder and sent only once the server has finished outputting them. The fast onslaught of tiny requests was causing occasional failure in Nginx.

If you use either of these server, please test them out and let me know of any issues you might encounter.

Sincerely,
Brian Nickel

THIS WEEK’S ACCOMPLISHMENTS

This week saw an explosion of development activity. Daily commits yielded a Changelog 234 lines (or 64%) larger than the week before. Key features are as outlined.

• Support was added for serving on a new Unix socket, as opposed to a piped socket or TCP socket. This can be used in several web servers in place of TCP sockets.
• Started work on documenting how to configure servers. Lighttpd and Cherokee are completely documented, Abyss is documented except for a bug appearing in ASP.NET 2.0, and the current problems with Apache2 are documented.
• Support was added for setting all command line options via environment variables, due to limitations in some servers. (MONO_FCGI_SOCKET=tcp is the same as setting /socket=tcp)
• Directories containing a “bin” directory are automatically treated as new applications. This is not a perfect way of checking for applications, as it can yield false positives, and not all applications use DLL’s, but it is pretty good for now.
• Support was added for writing to a log file.
• UnmanagedSocket now appropriately flags a closed connection.
• Sending and receiving records was redone, partially because I didn’t fully understand how reading and writing sockets worked and the request would die if Receive didn’t yield the exact number of bytes requested.
• When targetting .NET 2.0, Mono.FastCgi uses strictly generic collections. This reduces the size of the heap and should speed things up slightly.
• Records are now sent at no more than half the maximum size to avoid problems with some web servers. This behavior is similar to that of Cherokee.
• My patch to System.Net.Sockets.Socket was accepted. This patch is important because it removes the limitation of only supporting Unix and TCP sockets. (And may save some resources by not loading Mono.Unix if it isn’t needed.)
• Tons of bug fixes.

and

FastCGI Mono Server can handle full blown applications, like mojoPortal:

This is not hosted on a virtual path, but automatically recognized because the application contains a “bin” directory.

PLANS FOR THE COMING WEEK

1. I’m going to continue my work documenting servers. Each server presents different problems and test cases I may have overlooked and extends the reach of Mono.FastCgi.
2. Work with my mentor on what to do next.

CHALLENGES I’M FACING

I’m not sure how I want to proceed with the socket issue. It turns out all the problems I was having stemmed from bad implementation on my part and problems in mod_fcgid. Now that they’re overcome, the unmanaged socket is working fine. Not adding a mono specific feature to System.Net.Sockets.Socket would allow me to keep the version dependency down, make things easier if building it against MS .NET in the future, and give me an abstraction for using Named Pipes on Windows.

Another challenge is how to proceed with Apache. Admittedly, there are two existing open source implementations, both with their flaws, but both lacking things like Bugzilla, and both with highly cryptic source code. It may be best to develop a new FastCGI module under the Mono Project umbrella, to protect the project’s interests. It could be based off code from mod_mono and design attributes from my FastCGI library.

RESOURCES USED THIS WEEK

• MojoPortal forums.
• Abyss documentation.
• Wrapper scripts for other applications.

Sincerely,
Brian Nickel

Last Friday, I made it possible to compile and install your own copy of “fastcgi-mono-server” using standard methods. Now I have some in depth information on how to configure your server and what to look out for.

lighttpd

Lighty works fantastic. With about 5 minutes of configuration, you can get ASP.NET and all its glory running. Simply follow the instructions located here or in the “doc/linux/” directory of the source package.

cherokee

Cherokee, up to and including Cherokee 0.5.6, has a bug where it fails to send an empty Stdin record if no input data is present. I could write a hack to get around this problem, but I’m holding out for now. The Cherokee 0.6 series, on the other hand, works very well with fastcgi-mono-server. If you’re ready to move to the 0.6 series, follow the instructions located here or in the “doc/linux/” directory of the source package.

apache2

Apache’s FastCGI situation is problematic. There are currently 2 implementations of FastCGI that I’m aware of: mod_fastcgi and mod_fcgid, and neither one of them is working just right. Mod_fastcgi was designed by the authors of FastCGI to be a replacement for CGI (hence the name), and is strongly tied to the paradigm of each file being its own application. It does have some tricks which would let a single server be used, but it sends some very unusual and sometimes junk parameters back to the server. It would require some major hacks to transform its parameters back into values that the server could understand.

Mod_fcgid, on the other hand, has the advantage of being younger, hipper, and more in tune with the concept of script servers. It is almost perfect except for the fact it sends the entire contents of the response to the server rather than stripping off the status line and sending it as r->status_line. This causes Apache to reject the response and display an error message. fastcgi-mono-server doesn’t send a status line of the status is 200 (Ok), so it’ll only work for pages that don’t do anything fancy or crash.