| By Basil Voronkov at 2008-12-19 |
Starting from Beta 2 WideStream supports custom extensions. Moreover it is possible to add a support for a new protocol (by default only HTTP and FTP are supported) without the need to make any changes to the rest of the application. Also you may implement custom download adapters (see previous blog entry for details) as well as custom browser integration providers.
Basically all you need to do is to create a manifest.xml file and place it in the same folder where WideStream is installed. By default an application has an embed manifest that includes configuration of HTTP, FTP protocols and other standard functionality. You can take a look at the standard manifest in the project repository . When you create a custom manifest.xml file in the application folder it is processed in addition to the standard one.
For now manifest has three sections - Integrations, Protocols and Adapters. Inside each of the sections you can declare your own add-in by providing add-in name, description, a fully qualified name of the implementation class and, depending on the add-in type, a fully qualified name of the add-in options class.
As you can see native WideStream functionality such as FTP download support which is present since the very first public release is now being "added" to the application as an add-in. (By the way you can find a list of all active add-ins using a new Add-Ins dialog accessible from Tools->Add-ins menu).
What this functionality gives? For example, WideStream can't download from your favorite site (that requires to perform some actions such as submission of HTML form with some site specific information prior to download) - there is no problem at all, just create your download adapter as it is done now for the VBulletin attachments or YouTube video. WideStream doesn't support integration with your browser? You can teach it how to integrate with it.
Moreover if you are planning to implement your own network application - for example an SSH/SFTP client - you don't have to create all the application from scratch. You can use all the functionality that is already implemented in WideStream such as configuration engine (user interface for your settings is being generated dynamically based on your Options class), host manager, download queue management and much more. You can concentrate your effort on the SSH/SFTP client implementation and save up a lot of time. |
| By Basil Voronkov at 2008-10-10 |
| Last versions of .NET Framework have a pretty functional API that allows to work with HTTP and FTP protocols through the convinient object model instead of using sockets directly (which was the only way in the very first .NET Framework version as far as I remember). And yes, this API is currently used by WideStream.
I don't want to discuss a question of its limitations or functionality - that's a separate topic I believe. The thing that I want to describe here is the API architecture.
Basically this network API uses an Abstract Factory pattern which provides a high level of class polymorphism. No need to write almost duplicating chunks of code when everything can be generalized and therefore easily maintained and supported. As a result obviously different protocols can be dealt with in a really similar manner - theoretically you can use the same code to work with HTTP and with FTP as well.
The Factory, represented as a WebRequest class, defines a static non-instance Create method that accepts an URI - and depending on the protocol scheme used in this URI returns either an instance of HttpWebRequest or an instance of FtpWebRequest class, generalized using this super class WebRequest. WebRequest in its turn has a whole listing of virtual methods that are applicable for both FTP and HTTP - you can obtain a request in a synchronous or in an asynchronous manner, set credentials, configure authentication and timeout, choose a proxy and so forth.
That is cool. With no doubt. And really - if your task is to write a small routine that simply grabs something from the "outside" in a protocol independent manner - that is exactly what the doctor ordered. However when we come to really using all these staff the situation becomes not so obvious. To be perfectly honest I doubt that this is a revelation to somebody who have ever dealt with HTTP and FTP as soon as except of a general process workflaw these protocols don't have much in common.
The natural intention or better to say an instinct of a developer who discovers such an API is to follow its architecture and therefore to implement a generic or polymorphic DownloadProcess class. But as soon as there are a lot of actions and a lot of settings specific to FTP and HTTP you will finally find out that most part of this class contains a not very generic code. In other words your program has to ask all the time - Hey, what is this WebRequest thing? Is it actually an FTP or an HTTP request? As a result your code is full of C-casts and methods specific to one of these protocols. Polymorphism, eh?
Of course its not the API whom you should blame, its a developer who didn't oversee these pretty obvious difficulties. But then again if this .NET Framework API is dedicated not only for the simplistic network actions could it be designed differently?
That's a hell of a question. And it doesn't have a direct answer. Of course .NET Framework API is a generic API and this WebRequest class can be used to browse FTP directory as well to download a file through a secure HTTP connection. And if it will be implemented in a less pattern-oriented manner somebody will definetly ask - why don't you use Abstract Factory here?
So what's the conclusion? If there is any other pattern that better fits here?
This post is not about patterns. The quality of software architecture is defined not by the number of patterns that you are using but by the quality of the initial abstractions chosen for your architecture. What .NET Framework designer tried to achieve with this WebRequest class chain? It doesn't seem like a low-level network API - for this goal sockets and probably FtpClient style helper classes will be more than enough. High-level object oriented architecture? A generalized WebRequest and say an FtpWebRequest that may seem a concrete implementation of WebRequest (which is of course true) but at the same is again an abstraction of everything that can be done through FTP protocol. Using a concrete protocol as an abstraction is not the best choice I believe.
How else it can be done?
I'd say that we have a number of workflows that describe the typical tasks and processes. For example, Explorer style workflow. So we can implement an Explorer abstraction and it doesn't matter what exact implementation may be utilized here - it may be file system, FTP, SFTP, WebDAV or whatever. No doubt there are a lot of differences in concrete implementation of file system and FTP explorer but as soon as you have a right abstraction, a right building block, the rest becomes just a manipulation with ready-to-use high level blocks like in a Lego constructor. Remember that you will have Authorization abstraction, Listing abstraction and so forth. Imagine how clean the code will be.
But in reality I am not absolutely fair. I am not trying to design a new framework or something like that - the new Mekong milestone is becoming closer and closer and now I realize that a lot of solutions chosen for Murray... may require some serious attention in Mekong. WebRequest API (including the whole download process architecture) is definetly one of them. |
Project Blog 