[Mono-dev] Landing: System.Web

Miguel de Icaza miguel at novell.com
Fri Aug 26 00:08:50 EDT 2005


Hello,

    Just a heads up: tomorrow we will disable the System.Web directory
from compilation for a few hours as we land some fairly large changes to
it.  We hope to complete the merging tomorrow, but if something goes
wrong we might spend some time over the weekend.

    The new version of System.Web to be landed contains:

	* Tests: 67,700 lines of new tests:

		* NUnit test suite for about 50% of the controls.

		* standalone tests.

	* JSUnit: a new JavaScript unit test framework to automate
	  running the tests for various web controls and validate
	  that they do the right thing.

	  Similar in spirit to NUnit, but for web pages.

	* Unmanaged I/O: the new implementation uses unmanaged buffers
	  for uploads (HTTP POST for example) and content generation
	  as opposed to the managed buffers that we have today, which
	  greatly reduces the pressure on Mono's GC and also avoids
	  redundant copies of data by sharing buffers as much as 
	  possible improving performance.

	* Use of TCP Cork on Linux to avoid TCP glitches and delays,
	  this reduces the latency to get a full page.

	* Support for Linux sendfile to transfer static pages (support
	  for more platforms will come later).

	* XSP now transfers Socket ownership to the AppDomain to 
	  avoid round trips and expensive AppDomain boundary crossing
	  increasing performance.

	* New controls: about 40% of the existing controls were
	  rewritten from scratch with test suites to validate their
	  output.

	* New application pipeline: a new iterators-based design
	  reduces the complexity and increases the maintainability
	  of the old version.  

	* Support for HttpClientCertificate on XSP, soon to come
	  to Apache.

	* Improved tracing support.

    Latency has been reduced in various key places and the new unmanaged
buffers accelerate the processing of medium and large sized pages (small
pages remain about the same speed) and large uploads wont disrupt your
Mono process.

Miguel.



More information about the Mono-devel-list mailing list