Remove duplicate paragraph in overview

Author: Cito

docs/overview.rst

@@ -34,7 +34,6 @@ Another key goal of the original project was to provide a "Pythonic" API, instea
 The plug-in architecture has also been kept in Webware for Python 3, but now implemented in a more modern way using entry points for discovering plug-ins. Old plug-ins are not compatible, but can be adapted quite easily. The old Webware for Python installer has been replaced by a standard setup.py based installation.
 
 The most incisive change in Webware for Python 3 is the discontinuation of the threaded application server that was part of the built-in "WebKit" plug-in and actually one of the strong-points of Webware for Python. However, a threaded application based architecture may not be the best option any more for Python in the age of multi-core processors due to the global interpreter lock (`GIL`_), and maintaining the application server based architecture would have also meant to maintain the various adapters such as ``mod_webkit`` and the start scripts for the application server for various operating systems. This did not appear to be feasible. At the same time, Python nowadays already provides a standardized way for web frameworks to deploy web applications with the Python Web Server Gateway Interface (`WSGI`_). By making the already existing Application class of Webware for Python usable as a WSGI application object, Webware applications can now be deployed in a standardized way using any WSGI compliant web server, and the necessity for operating as an application server itself has been removed. Webware for Python 3 applications deployed using ``mod_wsgi`` are even performing better and can be scaled in more ways than applications for the original Webware for Python that have been deployed using ``mod_webkit`` which used to be the deployment option with the best performance. During development, the waitress_ WSGI server is used to serve the application, replacing the old built-in HTTP server. As a structural simplification that goes along with the removal of the WebKit application server, the contents of the WebKit plug-in are now available at the top level of Webware for Python 3, and WebKit ceased to exist as a separate plug-in.
-The most incisive change in Webware for Python 3 is the discontinuation of the threaded application server that was part of the built-in "WebKit" plug-in and actually one of the strong-points of Webware for Python. However, a threaded application based architecture may not be the best option any more for Python in the age of multi-core processors due to the global interpreter lock (`GIL`_), and maintaining the application server based architecture would have also meant to maintain the various adapters such as `mod_webkit` and the start scripts for the application server for various operating systems. This did not appear to be feasible. At the same time, Python nowadays already provides a standardized way for web frameworks to deploy web applications with the Python Web Server Gateway Interface (`WSGI`_). By making the already existing Application class of Webware for Python usable as a WSGI application object, Webware applications can now be deployed in a standardized way using any WSGI compliant web server, and the necessity for operating as an application server itself has been removed. Webware for Python 3 applications deployed using ``mod_wsgi`` are even performing better and can be scaled in more ways than applications for the original Webware for Python that have been deployed using ``mod_webkit`` which used to be the deployment option with the best performance. During development, the waitress_ WSGI server is used to serve the application, replacing the old built-in HTTP server. As a structural simplification that goes along with the removal of the WebKit application server, the contents of the WebKit plug-in are now available at the top level of Webware for Python 3, and WebKit ceased to exist as a separate plug-in.
 
 The second incisive change in Webware for Python 3 is the removal of the "MiddleKit" as a built-in plug-in. This plug-in served as a middle tier between the data storage and the web interface, something that nowadays is usually done with an object relational mapper (ORM_) such as SQLAlchemy_. MiddleKit was a powerful component that many users liked and used in production, but was also pretty complex, with adapters to various databases, and therefore hard to maintain. It made sense to swap it out and provide it as a separate, external plug-in if anybody is willing to take it over as a project and maintain it. Also removed were the "CGIWrapper", "COMKit" and "KidKit" plug-ins, because they have become obsolete or outdated. The other built-in plug-ins were less complex than MiddleKit and were kept as built-in plug-ins of Webware for Python 3. Particularly, "PSP, "UserKit" and "TaskKit" are still available in Webware for Python 3.