Google's Summer of Code: Part II

Mono/ASP.NET Visual Designer

Name: Michael Hutchinson
Contact: [email protected]
School: University of Durham, UK
Major: Physics
Project: ASP.NET GUI Designer
Project Page: http://svn.myrealbox.com/viewcvs/trunk/aspeditor/
Mentors: Miguel de Icaza
Mentoring Organization: Mono Project (http://www.mono-project.com/)

ASP.NET Web Forms is a server-side technology for creating event-driven interfaces in web browsers using browser postbacks and a view-state persistence mechanism. Widget functionality is encapsulated in components called “Web Controls,” which generate HTML markup, expose properties, and raise events.

The ASP.NET Graphical Designer provides developers with a user-friendly way to develop ASP.NET Web Forms pages on the Linux Mono implementation of .NET. The graphical designer, codenamed “AspNetEdit,” lets users add web controls to a design surface from a Toolbox, drag and resize them, and examine and change their properties with the Property Grid. In addition, it is a basic HTML graphical editor, enabling users to design complete web pages. AspNetEdit is not a complete IDE, as it aims to be integrated into the MonoDevelop IDE to provide a complete editing experience for the .NET languages that can be used to develop ASP.NET pages.

AspNetEdit was based on an existing HTML editor, the Mozilla editor. Unfortunately, the GtkMozEmbed GTK widget, which was used to integrate Mozilla into AspNetEdit’s GTK#-based UI, only exposes basic browser functionality and a C++ interface to the Mozilla internals. To circumvent this limitation, a small C++ interop library was written, allowing JavaScript in the browser to invoke C# methods in the host, and vice versa.

AspNetEdit needs to treat web controls (typically made up of a variety of HTML elements) as a single entity. Blagovest Dachev’s Summer of Code project implemented the XUL/JavaScript necessary to extend the Mozilla editor to treat the specified blocks of HTML as complete entities.

The C# host aspect of AspNetEdit is responsible for initializing and tracking the web controls and providing them with design-time services such as reference tracking and event binding using the .NET component model. It also has to parse and persist complete ASP.NET pages to provide saving and loading capabilities. The reflection capabilities of .NET/Mono were particularly useful, as the ASP.NET assemblies have a lot of metadata that specify how the controls should be treated in a designer and at runtime.

Back to Top

NDIS Network Driver

Name: Alan Ritter
Contact: [email protected]
School: Western Washington University
Major: Computer Science
Project: NDIS Network Driver
Project Page: http://netbsd-soc.sourceforge.net/projects/ndis/
Mentors: Phil Nelson
Mentoring Organization: The NetBSD Foundation (http://www.netbsd.org/)

For my Summer of Code project, I ported the FreeBSD NDIS code (aka Project Evil) to NetBSD. The purpose of this project is to gain the ability to automatically generate a NetBSD device driver for a network card from a Windows binary. To create the NetBSD driver, you first generate an ndis_driver_data.h file from the Windows .inf and .sys files using the ndiscvt utility. This C header is then compiled with the sources in src/sys/dev/if_ndis/ to produce a NetBSD driver for the card. Before this driver will work, however, the src/sys/compat/ndis/ files must be compiled or loaded into the kernel.

My work thus far has produced a functional NetBSD driver for a wired PCI card (an Intel EtherExpress Pro/100). As the Windows Driver Development Kit includes the source code for this card's driver, it was a natural choice. Having the sources for the Windows driver has greatly helped in debugging, as I can insert DbgPrint()s to trace through the code (prior to this, I had to step through i386 assembly to diagnose problems inside the Windows binary). At this writing, I have a driver working well enough to get an IP assigned via DHCP, and programs such as ssh and web browsers function relatively well. I'm still having problems, however, with the driver freezing during large downloads, and after much debugging, I'm positive this is due to synchronization issues.

Synchronization has turned out to be the most difficult part of this project, as FreeBSD and NetBSD are quite different when it comes to kernel threads and locks. Without going in to too much detail, I should explain that FreeBSD's interrupts have a thread context, so they can sleep, while NetBSD's interrupts have no context. In NetBSD, the only way to synchronize execution between the top and bottom halves of the kernel is to raise the processor priority level to block interrupts from being delivered.

Working on this project has been a great experience for me; I am very grateful to Google, my mentor, and NetBSD for this opportunity. I've always wanted to work on an open-source project, but had a hard time finding a place to start. This program gave me the extra push I needed to get started in open source.

mod-cache-requester: Improving Web Server Performance

Name: Parin Shah
Contact: [email protected]
School: University of Texas at Dallas
Major: Computer Science
Project: mod-cache-requester
Project Page: http://sourceforge.net/projects/cache-requester/
Mentors: Ian Holsman
Mentoring Organization: Apache Software Foundation (http://apache.org/)

Efficient cache mechanisms can significantly improve web server performance. The Apache web server has implemented caching modules including mod-cache, mod-mem-cache, and mod-disk-cache. To leverage most of any caching architecture, it is important that all popular pages remain in the cache all the time.

In the current Apache web server caching architecture, a page is removed from the cache on expiration. When that page is requested again, it cannot be served from the cache if the server has not regenerated the cached version of that page. This could lead to server "thunder herd problems. The Apache mod-cache-requester module keeps track of all popular pages and re-requests such popular pages when the page is soon to expire. (When a page's expiration time-current time is less than CacheRequesterSoonToExpireTime, it is declared as a "soon-to-expire page.) Thus, the page is reloaded with a new expiration time. The cache requester keeps track of the number of hits for all soon-to-expire pages to estimate the popularity of such pages. Stating "counter only after a page is soon to expire allows the cache requester to distinguish between current popular pages (those with very high request numbers in the past, but now losing popularity, which should not be reloaded in the cache) and prospective popular pages (those that had a high number of recent requests and should be reloaded in the cache).

The cache requester also has threads running in the background that request popular pages. Received data is discarded by the threads as the purpose of reloading the pages is already served. All such requests created by the cache requester are marked, indicating that they are not genuine requests, should not be served from the cache, and should actually be used to reload the cache. While such a page is being reloaded, all genuine requests are served from the cache.

There is a security concern with this method-an attack on the server involving a lot of requests with the marker set indicating that they come from the cache requester, so the server will keep reloading a page in the cache even though it's really a fresh page. To prevent this, all requests made by the cache requester carry a secret code to verify their authenticity.

Directives to configure mod-cache-requester include:

• CacheRequesterThreads, the number of background threads running.
• CacheRequesterMaxQueueSize, the size of the queue that stores information about the pages to be rerequested.
• CacheRequesterSoonToExpireTime, the expiration time remaining (in seconds) when a page is declared as soon to expire.
• CacheRequesterSecretCode, the secret code to prove authenticity of requests.

The libraries used include apr/apr-utils and libcurl.

Charting for XWiki

Name: Sergiu Dumitriu
Contact: [email protected]
School: Alexandru Ioan Cuza University, Rumania
Major: M.Sc. student, Computational Optimization and Distributed Systems
Project: Charting XWiki Tables
Project Page: http://www.xwiki.org/xwiki/bin/view/Dev/ChartDemo
Mentors: Ludovic Dubost
Mentoring Organization: XWiki (http://www.xwiki.org/)

Charting for XWiki is a project intended to create an XWiki extension that lets users easily generate and embed professional-looking charts (pie, bar, line, area, and time) in wiki pages. The generated charts dynamically reflect the contents of a data source (an XWiki table, for instance), which are simply instances of wiki text that use the {table} macro to delimit rows of data in which cells are separated by the pipe character (|). The charting extension was designed to be flexible enough to allow future extension to other kinds of data sources, such as database tables and views, XML documents, or symbolic mathematical functions. This can be done by implementing the DataSource interface, which allows for retrieving data through a table model (row, column, cell...).

The XWiki Charting extension is implemented as an XWiki plug-in that renders charts through JFreeChart (http://www.jfree.org/). The plug-in exposes the generateChart() method of ChartingPluginApi to XWiki scripts. The radeox {chart} macro provides a declarative way of specifying chart parameters in an XWiki script and initiating chart generation via the plug-in. The Charting Wizard provides many ways to customize the generated charts by setting some of its 150 parameters through a sophisticated AJAX user interface. One use of AJAX is to allow the selection of pages that have tables. When users have chosen the pages they want to work with, AJAX loads these pages and presents only the appropriate tables in order to choose the columns and rows for which to build the chart.

PyFileServer: Sharing Filesystem Directories

Name: Ho Chun Wei
Contact: [email protected]
School: National University of Singapore
Major: Computer Engineering, Master of Science
Project: PyFileServer
Project Page: http://pyfilesync.berlios.de/pyfileserver.html
Mentors: Ian Bicking
Mentoring Organization: Python Software Foundation (http://www.python.org/)

The aim of the PyFileServer project is to implement a WSGI-based web application for sharing files and other resources using the WebDAV protocol (http://www.webdav.org/specs/rfc2518.html).

The Web Server Gateway Interface defines a simple and universal interface between Python web servers and web applications, and among intervening web applications (termed "middleware). PyFileServer middleware includes:

• An Error Handler for translating exceptions into proper HTTP responses.
• A Request Resolver that supports multiple shares and resource types on a single server.
• A User Authentication module that implements both basic and digest authentication schemes.

The WebDAV Server application implements up to class 2 of the WebDAV specification, including resource locking and setting arbitrary properties. It also supports conditional processing headers and single-range retrievals.

The application uses a generic Resource Abstraction Layer interface that can be implemented to share any type of resource. The application includes a number of layers for sharing files (by default) and other resources such as a MySQL database.

The Domain Controller interface provides user information for authentication purposes, and can be implemented to support custom user databases. PyFileServer currently provides components for authentication against preconfigured users or a Windows NT domain.

The Lock Manager and Property Manager interfaces provide locking and arbitrary properties support and are implemented as persistent file stores. These can be extended to provide integration with resource-management systems for improved workplace collaboration or semantic classification.

Testing is done with the neon litmus test suite, cadaver, and Windows Web Folders. Standalone and in-code documentation is done in reStructuredText, then compiled to HTML. We use setuptools for packaging and distribution.

PyFileServer is released under the Lesser GNU Public License and requires Python 2.4 or higher. The package includes a simple WSGI web server and can be run either as a standalone application or imported into a WSGI-compatible web framework such as Webware (http://www.webwareforpython.org/) or Paste (http://pythonpaste.org/).

Back to Top

Fluid Simulation with Blender

Name: Nils Thuerey
Contact: [email protected]
School: University of Erlangen, Germany
Major: Ph.D. candidate, Computer Science
Project: Fluid Simulation with Blender
Project Page: http://wiki.blender.org/bin/view.pl/Blenderdev/SoCFluidAnimation/
Mentors: Jonathan Merritt
Mentoring Organization: The Blender Foundation (http://www.blender.org/)

The goal of the Fluid Simulation with Blender project was the integration of the free surface fluid solver developed at the system simulation group (LSS) in Erlangen, Germany into the Blender graphics toolset (3D modeling, animation, rendering, and the like) and to publish it as open-source software.

One of the biggest problems was the exchange of simulation data with Blender. During a full run, huge amounts of data are usually produced. However, as for visualization, only the fluid surface itself is of interest-the solution was to restrict the exchange to triangulated surface meshes. One of these can still contain several hundred thousand triangles per single frame of animation. Hence, two versions are generated and stored on disk in a binary format: a low-resolution preview for a quick estimation of the overall motion, and a compressed high-resolution mesh that is loaded for the actual image generation with raytracing. The compression is done with the zlib-Library, and results in a reduction of the mesh file sizes by 40 percent on average. The preview meshes usually contain only a few thousand triangles each, and thus can be streamed from disk and displayed in real time with 25 frames per second on a standard PC.

At the conclusion of the 2005 Summer of Code, the fluid solver can be fully controlled from within Blender, and thanks to the active developer community, many users are already testing the integration. It is planned that the fluid simulation code will be part of the next Blender release in the fourth quarter of 2005, and the work on it will continue after the Summer of Code program has ended.

DDJ