I am a Web Application Developer based in Johannesburg, South Africa and I have written about optimising the ASP.NET generated HTML more than once. I thought it would be appropriate to explain what I mean when I refer to the South African bandwidth environment. The answer comes in two parts, firstly the cost of bandwidth in South Africa and second the availability of internet access in South Africa. Let me tackle each separately.

The cost of bandwidth in South Africa

Firstly, the sake of simplicity I will assume a cost of $1 at R10.00, which will be close enough to reality to be acceptable. 

There are a few ways that one can connect to the Internet in South Africa, none are cheap. Let me list a few:

1. Dial-up, yes this is still a very popular way to connect to a service provider but is very limited in bandwidth but one of the cheaper options, starting at R79 per month plus call time.
2. GPRS through a GSM phone, mobile but also at a cool R2/Mb outside a data bundle.
3. ADSL, a sore point in this country as Telkom SA has the only network that supports it, a monopoly of grand proportion. A 1Gb/Month will cost  R145 plus the ADSL rental from a cool R152 per month for a 384kbps amounting to R297, it is worthy to note that there are fully inclusive offers that are cheaper at R199. It is also worthy to note that if you do not use the full allocated bandwidth given by the contract, it will be lost at the end of the month, so if one has used 500Mb the remainder 500Mb will be lost on the last day of the month, I call it theft but there is very little we can do.
4. iBurst, offers iBurst wireless from R49/Month for 40Mb at speeds up to 1Mbps, if you can get their signal.
5. 3G/HSDPA is offered by all South African mobile operators and even Telkom at a cool R2/Mb or on contracts from R179/Month for 350Mb and can achieve 1.8Mbps.
6. WiMax, offers from 64kbps but prices are generally not published so far.
7. Neotel’s, our 2nd fixed line operator, offers look good from R399 including Voice, 2.5Gb data, device and more. But more than that an extra Mb will cost R0.08 but they have a small foot print and do not operate everywhere yet.

Most of the above comes with a device (modem, router or other) that is calculated in the price over 12 or 24 months.

To wrap this off, there is no cheap way to access the Internet from South Africa but to compound the problem there is currently only one international bandwidth supplier in South Africa, Telkom SA, this will be changing in a few months but will it help? I’ll talk about that in Part 2.

If you wander why I have not published a single line of code from Project Banana, it’s because I am not happy with it yet.

I have some fully working code of version 1 with an engine but the architecture is wrong and it does not have CMS/SMS, it was a prototype to prove that certain aspects could be done. However, version 1 used too much bandwidth, was not search engine friendly (and could never be), was solely based on ASP.NET 2.0, could not make use of URL rewriting, was not maintainable and used ASP.NET Ajax which is too bulky for South African bandwidth.

Then I started version 2, keeping in mind the issues that were raised in version 1, I started to look for an ASP.NET platform to work form. I looked at a couple of approaches such as MVP Pattern as implemented in Web Client Software Factory which had 70% of my basic requirement out the box, however it was not going to work in a Medium Trust environment and needed major changes to do so, hence I gave it up, it may very well have been my worst decision. Then came ASP.NET MVC, though it only has 40% of my requirements, I thought it was to be my saviour, it may work beautifully for the public facing web application but would bring very little for the SMS, so I abandoned it but only for the SMS. I still think that the website API can work well with MVC. After much debate, I opted to try to create a base framework of my own, one I have now abandoned and let me explain why.

Firstly, my core requirements for the Site Management System (SMS) are as follows:

• Modular, plug in a new module maybe run an SQL script and voila the SMS functionality is working. This means that it will integrate itself into the SMS without the need to configure anything, in short copy a folder to the SMS and it auto-magically works, integrates into the menu, uses the SMS HTML layout, configurations and database without further intervention. (WCSF does most of this out of the box)
• Updatable modules, bug fixes should only affect the module affected and not break the site.
• Upgradable modules, assuming that the client wants to upgrade a module to something more complicated it should be as easy as copying it across and maybe run a SQL script, thus no loss of data. The upgraded module must be compatible with the previous module’s API and database.
• I also want to start using TDD for this as there are needs for backward compatibility and there will be more than one developer on this project sooner or later, something that “classic” ASP.NET does not provide. (WCSF does this out of the box)
• Highly optimized HTML output for fast responses in the South African bandwidth environment.
• Lastly, I want to secure the code at least for now until I decide on a licensing scheme, that will mean that the code will be compiled to 1 or more dlls and that there will be a licensing system on the master application.

So, as I embarked on my development mission to achieve the basic requirements above I found myself writing a solution that did what the Web Client Software Factory does, thus reinventing the wheel and wasting my time. After all, WCSF was written by the Microsoft Patterns and Practices team for us to use, and they kindly supply the entire code with a lenient licence. And it solves 70% of my problems. So, back to the drawing board it is, this time with the WCSF and having to learn IoC, TDD and more.

Project Banana 3.5.2 here I come, as for the version number well, nevermind.