Cloud Based Web Rendering?
Last night when working on my Silicon Graphics Origin 300 and suffering with an old version Mozilla circa 2005 as seen below:
I started wondering, these machines can function as a Web Server, MySQL server, firewall etc especially my Quad R14k Origin 300, yet web browsing is seriously lacking on them. Firefox 2 is available over at nekoware, but that is painfully slow. Granted I don't use my Origin for web browsing, but when I was using a R12k 400mhz Octane as my primary machine a few years ago as I am sure others around the world are doing it was painful. This problem I don't think is solely for those on EOL'd Silicon Graphics machines, but any older piece of hardware that does everything but web browsing decently. Thinking back to the Amazon Silk platform, using less powerful hardware, but a brilliant software platform, Amazon is able to deliver more with less.
The problem arises for the rest of the market because of the diversity of the PC/Workstation market. The way I see it you've got 2 approaches to a "universal" cloud web renderer. You could either:
- Write a custom lightweight browser tied to an external WCF/Soap Web Service
- Write a packet filter inspector for each platform to intercept requests and return them from a WCF/Soap service either through Firefox Extensions or a lower level implementation, almost like a mini-proxy
Plan A has major problems because you've got various incarnations of Linux, IRIX, Solaris, VMS, Windows etc, all with various levels of Java and .NET/Mono support (if any), so a Java or .NET/Mono implementation is probably not the right choice. Thus you're left trying to make a portable C/C++ application. To cut down on work, I'd probably use a platform independent library like Gsoap to handle the web service calls. But either way the amount of work would be considerable.
Plan B, I've never done anything like before, but I would imagine would be a lot less work than Plan A.
I spent 2 hours this morning playing around with a WCF service and a WPF application doing kind of like Plan A.
But instead of writing my own browser, I simply used the WebBrowser control, which is just Internet Explorer.
The Web Service itself is simply:
public JCW3CLOUDPage renderPage(string URL) {
using (WebClient wc = new WebClient()) {
JCW3CLOUDPage page = new JCW3CLOUDPage();
if (!URL.StartsWith("http://")) {
URL = "http://" + URL;
}
page.HTML = wc.DownloadString(URL);
return page;
}
}
It simply makes a web request based on the URL from the client, converts the HTML page to a String object and I pass it into a JCW3CLOUDPage object (which would also contain images, although I did not implement image support).
Client side (ignoring the WPF UI code):
private JCW3CLOUDReference.JCW3CLOUDClient _client = new JCW3CLOUDReference.JCW3CLOUDClient(); var page = _client.renderPage(url); int request = getUniqueID(); StreamWriter sw = new StreamWriter(System.AppDomain.CurrentDomain.BaseDirectory + request + ".html"); sw.Write(page.HTML); sw.Close(); wbMain.Navigate(System.AppDomain.CurrentDomain.BaseDirectory + request + ".html");
It simply makes the WCF request based on the WebBrowser control to read from. Nothing special, you'd probably want to add handling for specific pages, images and caching, but this was far more than I wanted to play with. Hopefully it'll help someone get started on something cool. It does not handle requests from with the WebBrowser control, so you would need to override that as well. Otherwise only the initial request would be returned from the "Cloud", but subsequent requests would be made normally.
This project would be way too much for myself to handle, but it did bring up some interesting thoughts:
- Handling Cloud based rendering, would keeping images/css/etc stored locally and doing modified date checks on every request be faster than simply pulling down each request fully?
- Would the extra costs incurred to the 3G/4G providers make it worthwhile?
- Would zipping content and unzipping them outway the processing time on both ends (especially if there was very limited space on the client)
- Is there really a need/want for such a product? Who would fund such a project, would it be open source?
Can do with Telerik’s Kendo
After playing around with Google Charts and doing some extensive C#/SQL integration with it for a dashboard last summer, I figured I'd give Telerik's Kendo a shot. If you're not familiar with Telerik, they produce very useful controls for WinForm, WPF, WP7 and ASP.NET controls (in addition to many others). If you do .NET programming, their product will save you time and money guaranteed. That being said, I started work on the first module for jcDAL last night and wanted to add some cool bar graphs to the web interface for the analyzer. About 15 minutes of reading through one of their examples I had data coming over a WCF service into the Kendo API to display this:
So far so good, I'll report back with any issues, but so far I am very pleased. A lot of the headaches I had with Google Charts I haven't had yet (+1 for Telerik).
IronPython + PLINQ?
Spent the afternoon reading IronPython documentation and finally got a chance to play with it a bit. I have to hand it to Microsoft for making it extremely easy:
var ipy = Python.CreateRuntime();
dynamic pyTest = ipy.UseFile("test.py");
Only 2 lines of code to have access to a python script. For me this opens new doors for scripting operations I still typically write in PHP because of the simplicity of opening notepad and pushing it out to an IIS server running PHP. Now I can write a few line C# app with an interface to run whichever script I wish to run.
Being curious about performance, I ported jcBENCH to use IronPython. To put it simply, the math operations pale in comparison to native C# math operations. The actual overhead in creating the Python Interpreter was negligible if anyone was curious even on an AMD C-50 (Dual 1ghz) Netbook with a OCZ Vertex 2 SSD.
Porting it did bring an interesting idea, this could work for a workflow process. The ability to process multiple workflows utilizing PLINQ, but with the flexibility to adjust the logic in script and not in the C# code.
jcBENCH Released
It's been a very long time since I released something, so without further adieu, I present jcBENCH. It's a floating point CPU benchmark. Down the road I hope to add further tests, this was just something I wrote on the airplane coming back from San Francisco.
You'll need to have .NET 4 installed, if you don't have it, click here. Or you can get it from Windows Update.
Click here to download the latest version. I'll make an installer in a few days, just unzip it somewhere on your machine and run.
Upon running it, the results get automatically uploaded to my server, a results page will be created shortly.
WCF + ASP.NET + AppFabric (Velocity) Caching == Awesome
Just getting started on a WCF Service that is going to be handling all of the business logic for the company I work for. With the amount of data, caching was a necessity. Was playing around with Membase last week, couldn't quite get it to work properly and then started yesterday afternoon with AppFabric. Microsoft's own answer to caching (among other things). It installs pretty easily, the built in IIS extensions are very cool. However the setup isn't for the faint of heart. To sum it up:
- Install AppFabric on your SQL Server with all of the options
- Then install AppFabric on your Web Server and create your WCF and ASP.NET sites
- From the PowerShell Cache console type:
New-Cache(Whereis the name you want to call it, so it could be: New-Cache RandomTexels- Verify it got created by:
Get-CacheIf you don't see it or get an error make sure the AppFabric Cache Service is running, open up the Run Window (Windows Key + R) and type: services.msc. It should be one of the top items depending on your setup.- After configuring your other server for .NET 4, usual web site permissions and settings in IIS then do this command:
Grant-CacheAllowedClientAccount DOMAIN\WEBSERVER$Replace DOMAIN with your domain name (ie MOJO) and WEBSERVER with the physical name of your webserver. So for instance:Grant-CacheAllowedClientAccount MOJO\BIGWS$for a domain callled MOJO and a WebServer called BIGWS. - Verify it got created by:
There's plenty of code examples o,,ut there, but as I create the architecture for this WCF I'll discuss my findings.


