I’ve been working full-time with a new open source project, OpenVideoPlayer, available at http://sourceforge.com/projects/openvideoplayer OVP is a cross-platform/technology web video player, with versions in both Flash and Silverlight. The project is sponsored by Akamai, Microsoft, Adobe, and others. The aim is to provide a good starting point for websites that need built-in players. We just released version 2.0 of the Silverlight player last Friday and it’s turned out to be quite a capable solution. The OVP started life as a media framework that Akamai provided to customers to make for an easier integration with their network. It was licensed as OSS for the 2.0 release in order to expand the community and involve other media companies and consumers.

It currently supports direct media links and standard playlist types, as well as MediaRSS feeds for consuming content from Content Delivery Networks like Akamai. We also created the technology behind SmoothHD.com, an adaptive streaming method that adapts Hi-Def content dynamically to play smoothly on nearly any system without buffering, regardless of bandwidth and hardware (within reason). The technology is currently a Microsoft and Akamai exclusive, and works with plug-ins for our player and on the server side with IIS 7.0. OpenVideoPlayer has a configuration page that generates the object tag for you, including parameters for the input source and visual settings.

If anyone has a need for a solid player in Flash or Silverlight versions, I encourage you to check it out and provide feedback on features you would like to see in the future. Upcoming features will include theming and easy re-styling, plug-ins for ad networks, and support for closed captioning. Theming is important to us, so OVP can be adapted to various sites and situations without significant changes to the core player classes. This way future revisions are much easier to roll out to customized installations. The next task at hand is updating SmoothHD.com to the latest player, and developing the theming system as I go. At that point I’ll some more in-depth posts about the guts of OVP. Cheers!

// Threading and User Interfaces

When doing GUI development on Windows you must very careful what thread you access a form or control from. Hopefully most Windows Forms developers know this by now, but in the early versions of the framework it could be a sneaky issue. As of .NET 2.0 they were kind enough to immediately cause an exception when a control was accessed from the wrong thread - forcing you to deal with it now instead of trying to figure out why you randomly get exceptions like this 6 weeks after deploying your application:

I wont delve much in to why this is necessary, there are plenty of explanations on the subject. The short story is that in .NET there is still a message loop that is running on the thread your form was run from, access from any other thread just isn’t thread-safe - you can’t use locking because it would block the user interface.
So let’s append the Async helper static class that we worked on in parts 1 and 2, giving it the ability to schedule tasks on the UI thread. This will go even further towards making an app cleaner and more maintainable.

UPDATE: This post is now an article on CodeProject.

// The old way of doing things.

Let’s say we want to update a TextBox in our application. Following with tradition I’ll show a few conventional ways to accomplish this, and then how we can do better. Here is what we are trying to do:

private void UpdateText(string myString){
    textBox1.Text = myString;
}

Simple as can be. Problem is when we want to run it from anywhere in our code. One way is to check if an invoke is required each time we run it. In this case I’m again using anonymous methods to keep things as clean as possible.

// ... //

// ask the control if we are on its UI thread
if(textBox1.InvokeRequired){
   //we are not, so an invoke is required.
   textBox1.Invoke(delegate{UpdateText("This is text");});
}else{
   //we are on the UI thread, we can directly modify the control
   UpdateText("This is text");
}

// ... //

A safer way is to build the invoke into the method itself. Note that this time I am using BeginInvoke, same concept but it does not block - it runs the task asynchronously.

private void SafeUpdateText(string myString){
    if(textBox1.InvokeRequired){
       //Invoke into this same method, but this time on the correct thread.
       textBox1.BeginInvoke(delegate{UpdateText(myString);});
	 return; //important, so we don't fall through
    }
    //this only runs if the above check says an invoke is not required.
    textBox1.Text = myString;
}

Hopefully that isn’t too confusing. If the Invoke is required we invoke our own method recursively, knowing that it will be on the right thread on the next time through. This isn’t too bad, but it can be a serious pain to make a method for every operation you need to do - once again its more things to remember and maintain, and more bloat for larger applications.

// The new method: Async.UI(…);

So know let’s fix up our Async class to make this whole process easier. I decided to make a separate method for this, ‘Do()‘ had enough overloads as it was and I wanted it to be very clear at a glance whether the task was UI related.

I’ll start with usage. Instead of all of the above, we can now do this:

//Method prototype: public static AsyncRes UI(Dlg d, Control c, bool asynchronous);
Async.UI(delegate { textBox1.Text = "This is way easier!"; }, textBox1, true);

Once again, something that might have needed a separate method and 5 to 10 lines of code, can know be distilled into a quick single method that takes care of the details for us. Let’s check see what those arguments are.

Our first argument is a delegate, same as we’ve done before - it can be an actual delegate instance, an anonymous method as above, or even a method without a parameter which .NET will silently wrap into a delegate.

The second parameter is the Control we’d like to invoke with. It can be the control you are accessing, our any of it’s parent controls/forms. Of course in the method you pass, you can modify as many controls as you like, provided they are all from the same form / UI thread.

Third is a bool that if true, tells the method to use BeginInvoke to make the call non-blocking. Otherwise the caller will block while the UI thread finds time to run your task.

// I, for one, welcome our new UI method overloads.

We have three more overloads with more and more options, first here are the prototypes:

// This re-introduces our ReentraceMode option, for thread safety and more control.
public static AsyncRes UI(Dlg d, Control c, bool async, ReenteranceMode rMode) 

// Now with the ability to grab a return value for you
public static AsyncRes UI(DlgR d, bool getRetVal, Control c, bool async);

// Pass a state object that is returned on an EndInvoke
public static AsyncRes UI(Dlg d, Control c, object state, bool async, ReenteranceMode rMode);

// And the last one, with all of the above.
public static AsyncRes UI(DlgR d, bool getRetVal, Control c, object state,
   bool async, ReenteranceMode rMode);

Got all that? It should all be pretty straight-forward. Now I’ll demonstrate using the last one with a return value.

// ... //

AsyncRes result = Async.UI(
	//make sure the delegate/method returns a value:
	delegate { return textBox1.Text; },
	true, //yes, we want to get the return value
	myForm, //the control to invoke on
	null, //the state object, we don't need to track anything.
	true, //invoke asynchronously?
	ReenteranceMode.Allow); //don't worry about thread safety in this case.

// .... do other things ... //

// now make sure the task above has completed.. 
result.AsyncWaitHandle.WaitOne();

//and use the value
Console.WriteLine("The textbox says: " + result.ReturnValue);

// ... //

That’s about as complicated as it gets now; even the most advanced usage of the new class is simpler than invoking the most basic UI tasks without it. The call to WaitOne is only needed because we chose to invoke asynchronously - we need to make sure it has completed or our value might be null. If we had passed a false to the async parameter the call would have blocked and the value would immediately be guaranteed to be there.

// The code that makes it happen.

This functionality has been added to the same Async class we’ve already been working with, and it makes use of much of the same code: all of our UI methods simply call the Do method internally, which has been expanded slightly. Here is the new signature of the Do method, along with a new blurb for handling UI:

// The private master Do method now also takes a control.
private static AsyncRes Do(DlgR dr, Dlg d, bool getRetVal, object state,
   bool tryThreadPool, ReenteranceMode rMode, Control control, bool async) {

// .. In the first part we still set up our delegate the same way as before //

if(control!=null) {
	res.control = control;
	res.result = AsyncAction.ControlInvoked;
	if (!async) {
		if (!control.InvokeRequired) {
			res.completedSynchronously = true;
			dlg();
		} else {
			control.Invoke(dlg);
		}
	}else {
		control.BeginInvoke(dlg);
	}
	return res;
} 
// don't catch any errors; if this fails
// we don't want it to continue below and get invoked in some other way

// .. the rest of the method, where we use thread or the threadpool
// .. only happens if the control was null, meaningth ecall was not UI related.

We were able to add quite a bit of functionality to this handy class, with only a few lines of code! The only other change is adding all of the UI overloads, each one simply calls Do with various parameters:

public static AsyncRes UI(Dlg d, Control c, bool async) {
	return Do(null, d, false, null, false, ReenteranceMode.Allow, c, async);
}

public static AsyncRes UI(DlgR d, bool getRetVal, Control c, object state,
  bool async, ReenteranceMode rMode) {
	return Do(d, null, getRetVal, state, false, rMode, c, async);
}

// .. and so on .. //

That’s all there is to it. Of course now we have some updated source code to share with you. The new zip file is the source in a VS2005 project, and the Async2.cs file has the entire source code for the previous posts, along with these new updates; now up to a 400 lines.

Again, let me know if you have any problems, comments, suggestions, questions, compliments, or threats of bodily harm - I’ll take them in stride.

*Coming in future posts of this series: Expanding this async concept into timers for recurring tasks, a handy stop watch, a throttling utility, and configuration file handling.

// The Code.

When we last were together, I spent entirely too long explaining the wrong and/or hard ways to start a quick asynchronous task in C#, and only gave a quick taste of what was to come with the Async helper class. This time I’ve got the source to back me up.

UPDATE: The first part of this series is now an article on CodeProject. Check it out and give it a vote for me.

// The main method: Async.Do(…);

Our Do() method is where most of the magic happens, although it is only 60 lines with generous comments. Sharp observers will notice a couple odd things: it is private, and it takes two different delegate parameters. There are several overloads, these in turn call this method passing one or the other delegate, depending on whether we need a return value. This cleans the caller’s code greatly.

Making one method that does the work keeps the important logic (and troubleshooting) in one place, but it is private as to not confuse the caller as to which delegate to use.

private static AsyncRes Do(DlgR dr, Dlg d, bool getRetVal, object state,
bool tryThreadPool, ReenteranceMode rMode) {
	//get a generic MethodInfo for checks..
	MethodInfo mi = ((dr != null) ? dr.Method : d.Method);
	//make a unique key for output usage
	string key = string.Format("{0}{1}{2}{3}", ((getRetVal) ? "<-" : ""),
		mi.DeclaringType, ((mi.IsStatic) ? ":" : "."), mi.Name);
	//our custom return value, holds our delegate, state, key, etc.
	AsyncRes res = new AsyncRes(state, ((dr != null) ?
		(Delegate)dr : (Delegate)d), key, rMode);

	//Create a delegate wrapper for what we will actually invoke..
	Dlg dlg = (Dlg)delegate {
		//checks for reentrance issues and sets us up
		if (!BeforeInvoke(res)) return;
		try {
			if (res.IsCompleted) return;
			if (dr != null) {
				res.retVal = dr();//use this one with a return
			} else {
				d();//otherwise the simpler dlg
			}<br />
		//we never want a rogue exception, it can't bubble up anywhere
		} catch (Exception ex) {
			Console.WriteLine("Async Exception:" + ex);
		} finally {
			//this will fire their callback and clean up
			FinishInvoke(res);
		}
	};

	//...//

		

So far we have obtained a MethodInfo object that gives more detail about the delegate we will be executing, created an instance of the AsyncResult custom class that will be returned to the caller for tracking, and then wrapped their delegate into another anonymous method/delegate that can be bandied about as needed. This wrapper also injects method calls for before and after the invoke, these help with locking for our reentrance as well as setting some properties on the result object.

Don’t worry, the overhead of this extra indirection of this wrapper method is remarkable small (I benchmarked it) unless you are talking thousands of tasks executing per second. If that is the case then you need to rethink your architecture. Now for the rest of our Do() method:

	 

	if (tryThreadPool) { //we are going to use the .NET threadpool
		try {
			//get some stats - much better than silently failing 
			//or throwing an expensive exception
			int minThr, minIO, threads, ioThr, totalThr, totalIO;
			ThreadPool.GetMinThreads(out minThr, out minIO);
			ThreadPool.GetAvailableThreads(out threads, out ioThr);
			ThreadPool.GetMaxThreads(out totalThreads, out totalIO);

			//check for at least our thread + one more in ThreadPool
			if (threads > minThreads) {
				//this is what actually fires this task off..
				bool result = ThreadPool.QueueUserWorkItem(
					(WaitCallback)delegate { dlg(); });
				if (result) {
					res.result = AsyncAction.ThreadPool;
					//this means success in queueing the item
					return res;
				} else {
					//according to docs, this "won't ever happen" 
					// but an exception instead.. who knows.
					Console.WriteLine( "Failed to queue in threadpool." +
						"Method: " + key);
				}
			} else {
				Console.WriteLine(String.Format(
					"Insufficient idle threadpool threads: {0}of{1}-min {2},
					Method: {3}", threads, totalThreads, minThreads, key));
			}
		} catch (Exception ex) {
			Console.WriteLine("Failed to queue in threadpool: " + ex.Message +
				"- Method: " + key);
		}
	}

	//if we got this far, then something failed, or they wanted a dedicated thread
	Thread t = new Thread((ThreadStart)delegate { dlg(); });
	t.IsBackground = true; //this & priority are candidates for additional settings
	t.Name = "Async_" + key;
	res.result = AsyncAction.Thread;
	t.Start();

	return res;
}
		

In the latter part of our method we check some threadpool stats to see if it is worth even trying to use it. If all is good, we queue up the delegate and we’re done. If it is out of threads or the user chose a dedicated thread, then we skip that hullabaloo and just make our own thread to run.

// Before and After methods

Injected into our wrapper delegate we have a BeforeInvoke and FinishInvoke. There are a few important concepts there so let’s check them out quickly.

private static bool BeforeInvoke(AsyncRes res) {
	//if marked as completed then we abort.
	if (res.IsCompleted) return false;
	//if mode is 'allow' there is nothing to check.  Otherwise...
	if (res.RMode != ReenteranceMode.Allow) {
		//be threadsafe with our one and only member field
		lock (methodLocks) {
			if (!methodLocks.ContainsKey(res.Method)) {
				// make sure we have a generic locking object in the coll. 
				// it will already be there if we are reentering
				methodLocks.Add(res.Method, new object());
			}
			//if bypass mode and we can't get or lock, we dump out.
			if (res.RMode == ReenteranceMode.Bypass) {
				if (!Monitor.TryEnter(methodLocks[res.Method])) {
					res.result = AsyncAction.Reenterant;
					return false;
				}
			} else {
				//Otherwise in 'stack' mode, 
				//we just wait until someone else releases it...
				Monitor.Enter(methodLocks[res.Method]);
			}
			//if we are here, all is good.  
			//Set some properties on the result class to show when 
			//and what thread we are on
			res.isStarted = true;
			res.startTime = DateTime.Now;
			res.thread = Thread.CurrentThread;
		}
	}

	return true;
}

Here we look for ’stack’ or ‘bypass’ modes which require locking, allow mode can just play on though. We first look for a locking object in our methodLocks collection, keyed by our delegate’s fully qualified method name. The lock object is unimportant, just something that can be synchronized against - I chose not to use any existing objects because the caller might have access to them - which could cause problems if they also decided to lock on them.

Once we have our lock we Monitor.TryEnter (and fail otherwise) in ‘bypass’ mode, or just Monitor.Enter the lock and wait forever for it to free in ’stack’ mode.

That collection is the only thing we keep track of at a class level - everything else cleans up itself. Now for our FinishInvoke:

private static void FinishInvoke(AsyncRes res) {
	if (res == null) return;
	try {
		//finish a few more properties
		res.isCompleted = true;
		res.completeTime = DateTime.Now;
		// set the resetevent, in case someone is using the handle to 
		// know when we've completed.
		res.mre.Set();
	} catch (Exception ex) {
		Console.WriteLine("Error setting wait handle on " +
			(res.Method ?? "NULL") + ex);
	}

	if (res.RMode != ReenteranceMode.Allow) {
		//if mode is bypass or stack, then a lock that needs releasing
		try {
			if (methodLocks.ContainsKey(res.Method)) {
				Monitor.Exit(methodLocks[res.Method]);
			}
		} catch (Exception ex) {
			Console.WriteLine("Error releasing lock on " +
				(res.Method ?? "NULL")+ ex);
		}
	}
}

In FinishInvoke we set a few more properties, including a ManualResetEvent that can be used by the caller to wait on this task’s completion. Then we release our lock to allow other instances of this task to proceed.

The overloads and AsyncResult class are about all that is left in the code, and they aren’t especially groundbreaking, so I’ll leave it to you to check them out. This zip file has a VS2005 project that I used to make sure this compiled by itself, and this Async.cs file has the entire source code, a little over 300 lines with lots of comments.

UPDATE: Part three of the series expands on this class, before downloading the code you may want to read the next part and get the source there with added UI functionality.

Later on I may post some interesting uses for this, as well as some expanded functionality that I’ve already been using. I hope this can be as useful to you as it has for me - use it in good health, and don’t hesitate to post questions, comments, or suggestions.

*Coming in future posts of this series: Async tasks in a Windows Forms GUI environment (Part 3), expanding this async concept into timers for recurring tasks, a handy stop watch, and configuration file handling.

// Series Introduction

I’m a sucker for clean and beautifully groomed code. In my experience maintaining a large code base with few resources, it is in fact the only way to keep sanity and keep from sliding into a pit of spaghetti. I’ve been on a push to find areas of necessarily messy or repeated code and find ways to make them more elegant and maintainable - this is the first in a series* of small classes and helpers that I kick myself for not doing sooner.

UPDATE: This post is now an article on CodeProject.

// The Problem at Hand

In any reasonably large application there are a lot of times when you need to perform a quick task asynchronously. One use off-hand is application that saves a log or status report to file on start-up. The operation is slow in relative terms since it involves file I/O, and we don’t have to worry much about other code paths depending on it. Making it asynchronous will speed up our start time with no risk of side effects.

// The Obvious and Ubiquitous Solutions

The .NET Framework makes this quite easy, we’ll show a few ways to accomplish it. However there are gotchas and keeping track of everything can lead to messier code, so I’ll introduce a helper class to make our lives easier. Of course exception handling and such is excluded from these examples for brevity.

Example Method. Lets say we have a method as such that we need to run async:

 private void SaveReport() {
      statusReport.Save(); //This takes a bit of time
      Console.WriteLine("Status report saved!");
 } 

1. Brute Force - create a new thread:

 ThreadStart ts = new ThreadStart(SaveReport);
 Thread t = new Thread(ts); <br />
 t.IsBackground = true; <br />
 t.Start();

Besides the chattiness here, this is not the most efficient way to get this done, unless you have a pretty long running task. For every action, a new thread with context and stack space will be created, just to be used for a short period. More effective is to utilize the .NET ThreadPool, and let it reuse a few preallocated threads on your behalf.

2. BeginInvoke. One way to use the ThreadPool in a round-about way is to make a delegate and begin invocation on it directly:

 MethodInvoker dlg = new MethodInvoker(SaveReport);
 dlg.BeginInvoke(null, null); 

3. Anonymous Method. I’ll also note that in .NET 2.0 we can use an anonymous method, saving us from defining the method separately. functionally this operates the same way as the previous.

 delegate {
	statusReport.Save();
	Console.WriteLine("Status report saved!");
 }.BeginInvoke(null, null);.

There is a problem with both of these examples as well, besides their messiness. The BeginInvoke method takes two parameters, a AsyncCallback for notifying when the operation completes, and an object that is passed through to that callback for the callers purposes, typically the original delegate. Now creating a callback just adds more trouble to this whole exercise, particularly if you do not need to know exactly when the operation completes. However, although not documented well, I’ve seen issues if the callback is not used to call EndInvoke, as such:

4. BeginInvoke with Callback. Here we will use a BeginInvoke on the delegate with a callback to inform completion:

 private void ReportCompleted(IAsyncResult result) {
	if (!result.IsCompleted) return;
	MethodInvoker dlg = result.AsyncState as MethodInvoker;
	dlg.EndInvoke(result);
 }
 //...//
 AsyncCallback asc = new AsyncCallback(ReportCompleted);
 MethodInvoker dlg = new MethodInvoker(SaveReport);
 dlg.BeginInvoke(asc, dlg);

No major issues now, but again - this gets very messy, especialy once you start creating a couple 5 line methods everywhere for each task.

5. ThreadPool. Another way is to go straight after the ThreadPool:

 WaitCallback wc = new WaitCallback(SaveReport);
 ThreadPool.QueueUserWorkItem(wc);

This is much more concise, but without the control over the process that we have in the above examples. A larger problem that I haven’t discussed is that any of these examples can fail spectacularly, or sometimes silently - any exceptions from your invoked methods will vanish into the ether. Once error handling (and logging, right?) is applied to both the action being performed, and the action of invoking it, and possibly to ending the invoke, we have a lot of code to just make a one-liner action happen safely asynchronous.

If this does fail, you may want to then attempt the action with a dedicated thread to make sure it works if the ThreadPool is not cooperating, that’s more code to bandy about.

A more subtle limitation I started to run into is the matter of reentrance. In the above example we are periodically saving a status report. What happens if it gets delayed? Its quite possible that the next time you invoke it the prior attempt is still in process, all kinds of mayhem could ensue. Now we need to add even more code for blocking and thread safety.

6. Thread-Safety: Blocking. This time we will use a lock to make our method blocking, it could then be invoked in any of the above ways.

 private readonly object reportLock = new object();

 private void SaveReport(){
	lock(reportLock){ 
		/* extra credit for why we didn't just lock our status report object! */
		statusReport.Save();
		Console.WriteLine("Status report saved!"span>);
	}
 }

Wait a second though - if one status report is a few minutes behind, we don’t need one to follow right on it’s tail. We also want to avoid getting multiple ThreadPool threads stacked up on each other, preventing other tasks. Let’s instead make this blocking into a bypass, and skip the next action if we get backed up:

7. Thread-Safety: Bypass.

 private readonly object reportLock = new object(); 

 private void SaveReport() {
	if (!Monitor.TryEnter(reportLock)) return;
	//if it is locked, just dump outta here..
	try {
		statusReport.Save();
		Console.WriteLine("Status report saved!");
	} finally {
        	Monitor.Exit(reportLock);
	}
 }

If you aren’t familiar with this syntax, the C# lock statement is just a shortcut for using the Monitor.Enter and Monitor.Exit calls appropriately. In this case we used the monitor class directly, with TryEnter so that it didn’t block forever.

So now we have at least seven different ways of skinning this cat, all with pros and cons. Every time you need to run a task asynchronously you must evaluate multiple options, worry about exceptions, copy and paste (ack!) more chunks of similar code around, and then maintain that code that clutters up the flow of your logic.

// A Better Way - The Async helper class.

What if we had some kind of magical helper class that had the power of any of the examples above, but was also incredibly concise? It would put all of this power in one place, so troubleshooting and changes and error handling and tweaks could be concentrated in one place. Come to think of it, such a class might even heal sick puppies! Here’s how we would use it:

 Async.Do(SaveReport);

What? How could it be that easy? Is this possible? Yes, all this can be yours, and more. .NET automatically takes any void method with no parameters and invisibly makes a delegate for it, which is how the above works by passing a method name, we can also pass delegates or anonymous methods.

 Async.Do(delegate {
	Console.WriteLine("I'm in an anonymous delegate!");
	statusReport.Save();
 });

// More advanced Async class examples

With some overloading and fancy footwork, we can also do any of the following:

/* this takes care of any of our locking and blocking and thread-safety woes. The ReentranceMode enumeration also has options for 'Stack' and 'Allow' */

 Async.Do(SaveReport, ReentranceMode.Bypass); 

 
 /* The bool parameter 'useReturnValue' instructs the helper to track the return value of your delegate/method if you ask for it later from the IAsyncResult that is returned : */ 
 IAsyncResult result = Async.Do(SaveReport, true);
 //do other stuff in meantime...
 // ...and if the action is not completed, wait for it to finish
 if (!result.IsCompleted) result.AsyncWaitHandle.WaitOne();
 Console.WriteLine("My result was: " + result.ReturnValue);

 /* Methods that take parameters can be wrapped in an anonymous method, the parameter will be psuedo-curryed for us by the framework. If the return value is important, we can also use a return inside the anonymous method! */

 Async.Do(delegate { return GetAnObject("A string parameter"); }); 

 /* our most advanced method signature has all of the options, as seen below */

 Async.Do(
	SaveReport, //our delegate or method
	false, //track return value?
	this, // a state object to be tracked with the IAsyncResult
	true, /* Use ThreadPool? true will attempt to use the threadpool, then fall back to a thread.
		False always uses a thread, for use with long-running tasks.*/
	ReenteranceMode.Stack); //our enum controlling how we handle multiple calls to the same action. 

So there it is, the best .NET Asynchronous helper class a geek could ask for. All the power of any other methodology with none of the bloat and maintainability issues. This class has greatly simplified code flow and literally cut thousands of lines of code from an large application. I’ve taken long enough just explaining the need and usage of the class, I’m going to save the implementation (and source code) for the next post.

Check back soon for the thrilling conclusion, and let me know what you think!

*Coming in future posts of this series: The code that makes this example work (Part 2), Async tasks in a Windows Forms GUI environment(Part 3), expanding this async concept into timers for recurring tasks, a handy stop watch, and configuration file handling.

The biggest thing for me is integration with Visual Studio.  There is a great SVN client called TortoiseSVN that is a shell extension to Explorer.  It works extremely well - and since it isn’t IDE-centric, it allows for easy use of SVN for your documents or just about any file resource.  The only problem is that if you move files in Visual Studio - say dragging a cs file into a sub folder of your project, or even adding a new class, SVN doesn’t pick up on the change.  Later you’ll realize your files didn’t get checked in and it can be a pain to find all of them.  VisualSVN to the rescue.  It is a Visual Studio plug-in that lets SVN know about the actions you make, keeping everything in sync.  you can also update or commit changes from the IDE.  It is a commercial project, but very inexpensive and very worth it.

There are tons of alternatives to Visual SourceSafe.  Some are expensive (Perforce, Clearcase) and designed for larger teams, while others are free/open source (CVS, SVN, etc..). Some even have neat-o comic advertisements in programming magazines.

* More to follow in a future post - experiences from building a new clustered datacenter.

There is way too much going on here.

I’ve been on both sides of this as a developer, and I understand the compulsion. It’s easy to dream of better applications that integrate everything you need into one place, until you realize the end result is one ginormical application for all tasks, doing all things but none particularly well, with more bloat than Uncle Ralph after Thanksgiving.  Instead of the Super-Deluxe All-You-Can Eat Fortune Buffet* method of designing software, let’s go for the specialist role. I want a music player that does one thing very well - play music.  I also want an Operating System that manages my files, memory, and processes - and stays out of my way for most of everything else.

The music player part is easy these days.  For GNU/Linux Amarok is excellent, and for Windows I highly recommend Foobar.  On the Operating System front, things aren’t as easy.  Windows XP (or Server 2003) can be beaten into submission fairly well, and that’s what I’ve been using on my Windows development workstation for quite a while, well since it was in beta.  It is certainly showing it’s age 8 years later though.  Vista is not as bad as some of the rap it has gotten, but it is bad enough that I don’t want to use it every day.  I love Linux and there are several distros I’d rather have in front of me all day, so I’ve given though to doing all development in a Windows Virtual Machine.  Lately I’ve also been using Server 2008 more and more, and have to say it’s an excellent O/S, so I’ve also thought of trying it as a workstation for a while.  I tell myself it is not much different than Vista, at least at a kernel level - but the speed difference and UI constancy improvements are drastic.

The key thing is that the development I do, regardless of where and how, will be kept overly simple.  How often do you complain an application is too simple, and can’t accomplish a task?  How often do you complain that an application is bloated, and slow, and controlling?  For me it is clear that the latter is much more common.  Create a program that serves a basic need.  Use it.  Then add features once you know you (or others) can’t live without them.

• - I’m going to use Python. I wanted to use a dynamic language that would be flexible. The heavy lifting is done by the plug-ins like Rdesktop / mstsc and VNC anyway, written in C - the surrounding application doesn’t need tons of speed. Ruby was a contender, but Python seems much more suited to cross-platform thick-client apps like this, at least at the moment.
• - I’m using the wxWidget library for a cross platform GUI. It is simple to use with Python, has a better look and feel than TkInter, and with less weight and licensing baggage than Qt.
• - I’ve decided to work on / test with Linux first. I do plenty of Windows Development at work, so this will give me a challenge to keep my interest. Once Linux is complete, porting a Windows version will be a breeze.

State of the application

Most importantly, it’s a running app - a big part of getting excited about building something! Now it may not be as complete as the screenshot would lead you to believe - the connections are hard-coded (only RDP is working so far), and it doesn’t actually know ‘new’ or ‘open’ or ’save’ like the toolbar would indicate, but it is making fast progress. Python has been surprisingly easy to work in after long stints in C# and C++ - if there’s interest I may just write a ‘Getting started in Python for .NET programmers’ tutorial.

I’m using WingIDE for editing - it is commercial, but I haven’t found anything as stable, elegant, and lightweight that was free (but not too lightweight like the included IDLE). If I don’t come with anything better in the eval period I’ll license or steal it. I mean license it. I originally tried also using wxGlade, a GUI designer for wxWidgets that can export to Python, but after getting accustomed to how it all fit together I decided to write the UI by hand: more control and more concise code. I just sometimes have to sketch layouts on paper to get started, since I can’t just drag things around until they fit - which wxGlade wasn’t great for anyway.

One big part I was dreading, going through the rdesktop code to integrate it with my UI, turned out to be a non-issue. Since I had last spent much time with it, rdesktop has added a parameter (”-X”) that takes a window id to embed itself into. All I have to do is launch it in another thread and pass it the id of my panel. Insanely easy, my integration with RDP is now about 20 lines of code. In fact, I should send the rdesktop contributor chocolates. It turned out to be a well written and easy to read program, but I was still pretty relieved - lets hope VNC is as easy.

What comes next?

So here are the biggest items on the radar -

• - Public source control. I like Subversion and could host it myself, although SourceForge or the like might get more publicity. Anyone have experience there? I’d love to get some collaboration going on this.
• - More information here on how I’m building it. I just need to get it broken down into article sized chunks and get to writin’.
• - I need a plug-in system. Python lends itself to pretty easy plug-in implementations, and there are a few complete libraries - although I’d like to keep dependencies to a minimum. Plug-ins will have to not only provide the ability for a new type of connection, they will also need to somehow provide a panel with config options. I haven’t quite yet wrapped my head around how interfaces work in a dynamically typed system
• - A configuration / settings-persistence system. I’m fond of serialization for this type of thing - making the actual usage as easy as possible. I haven’t spent many brain cycles on it yet, but it seems that Python would work well in a JSON-like format: just spit out Python code that will build the classes to a config file, and when loading it, evaluate the contents.

Expect fast progress from this point, I’m itching to get a usable app that I can start to dogfood…