Monthly Archives: June 2008

Skype on the move

Skype is a pretty complex program in the sense that it has quite a lot of options. However, one thing lacking is an option to configure where you want your data files stored. Whether it's history, pictures, received files, etc.. none of these are available for you to configure from the user interface. Now as a developer, I would think why haven't they built in this functionality? It doesn't take much to foresee that someone might want to change the location.

The funny thing is that they actually do have all of this built in. You can configure the locations of pictures and received files in the config.xml file that is in the data files folder. The entries are:

      <Avatar>C:\Documents and Settings\…..</Avatar>
      <AvatarPath>C:\Documents and Settings\…..</AvatarPath>
      <ContentPath>C:\Documents and Settings\….</ContentPath>

This is great, but where is the data folder located? Well by default Skype creates it in the Application folder (C:\Documents and Settings\User\Application Data\Skype) which kind of sucks for those of us that have our data on a different drive. There is no where in the options to change this. There's no configuration file in the application executable folder either. There's not even a registry entry. Nope. Skype have made it so easy that it's not even obvious. To change the location where your data is stored, pass it in on the command line:

skpe.exe /datapath:D:\MySkypeData

You can even make it portable by passing in /removable also. This prevents your password from being saved. Great for USB sticks.

What I find amazing is that if these developers have gone through the "hard" part of making this all configurable, why wouldn't they just add an option to the user interface?

Outlook doesn't suck after all

For the past couple of years I've had many problems with Outlook, but mainly one big problem: "The Data File did not close properly….." message that kept popping up every time I would close it down, reboot, restart, shutdown, go away, whatever…

In the past I've tried various mail clients, including but not limited to The Bat!, PocoMail and recently Thunderbird. In regard to The Bat! it is probably the most productive mail client that exists. It's extremely powerful (built in Delphi), yet it lacks two important things: a decent calendar/task list, and sync with PDA's. Keeping two contact lists is a PIA. So that's discarded. My experience with PocoMail/Barca (also built in Delphi) was limited and just didn't *do it for me*. I decided to try Thunderbird a couple of weeks ago, sick of Outlook. Found a Calendar plugin (Lightening) that was pretty decent (despite it's bugs) and away I went. Yesterday I switched back to Outlook.

Why? After several weeks of using Thunderbird, I gave up. Thunderbird is not a bad software but the developers have completely forgotten what usability is all about. There are some standard things that just don't work the way they should. Sure, I can run about:config, but why the hell should I have to? Don't make configuration options in a nicely designed dialog for stupid little things and then the basics leave hidden away. Lightening (which is Sunbird a la plugin) also has some really annoying bugs (like times not getting registered unless you EXPLICITLY LEAVE the edit boxes before saving).

So I kept going back and forth, and for a couple of years decided to stick with Outlook. It's integration with various applications is very time-saving and flexible. It's calendar is pretty decent and on the whole I'm happy with version 2007, except for this data corruption problem. I decided that after two weeks (and just before my trial ran out on BirdieSync) to give Outlook another try. So low and behold, yesterday I set out on a venture to try and find my problem with Outlook [for those with short term memory problems: Data File corruption].

Many people have reported that it's because Outlook doesn't close even after the window disappears, and resetting the machine causes corruption. That's true to a certain point, except in my case I can close Outlook, wait for it to close down entirely, open it up and get the data corruption each time.

My next bet was TrueCrypt, yet I couldn't find anything about this on the web, and I was NOT about to give up TrueCrypt. I had also heard rumors about AVG, but again, something I doubt. Then while going through the list of plugins installed in Outlook, it struck me. Could it be Google Desktop? I decided to uninstall the plugin, and since I mostly use GDT for Outlook search, I removed it entirely from my system. As of yesterday, all my data corruption problems seem to have vanished. Not only that, but my other problems with Outlook are gone too. No more taking up 100% CPU when checking mail, no more frozen Windows and no more slow operations. In fact, it's really fast now, considering my archive folder is 1.5 GB and my main one is crawly to just under 600 MB.

So now I have to find a replacement for GDT. Any suggestions? And no, I won't install Vista  (or Windows Desktop Search). The damn thing doesn't even work. I get better results with a dir /s when searching for a simple file.

Silverlight, Linq, Xml, Intraweb, Ajax and REST

I've updated the support for Silverlight in Intraweb to support the changes for the Silverlight 2 beta that has recently come out. To test the new functionality, I decided to put together a demo that shows how to not only use Silverlight controls, but to also interact with them using Intraweb. I then decided to take it one step further and use Intraweb as a service to provide data to the silverlight control.

Here I had two options: use Intraweb as a SOAP server, something that can be done very easily using Arcana's Elite Suite (now open source and available here) or use REST. I decided to choose SOAP so that I could show how easy it is. Unfortunately it didn't work. Not because Intraweb failed, nor did Arcana's components, but Silverlight did. It turns out that Silverlight has issues with certain web services.

So I had to opt for using REST, which in fact is good because it shows the simplicity and beauty of this architecture, where we get rid of the SOAP overhead. With
Intraweb, implementing a REST service is extremely simple. All that is required is to process the information in the OnBeforeDispatch and set the Handled property to True.

Since this is quite long (not that it's complicated, but I want to explain things with as much detail as I can), I've divided it up into several posts:

[Note: Integrating Intraweb and Silverlight is not complicated. The purpose of this demo is to show pretty much all the different things you can do and make use of a variety of technologies and techniques]

1. Creating the REST Intraweb Server

2. Consuming Data from Silverlight

3. Talking to Intraweb Controls from Silverlight

4. Talking to Silverlight Controls from Intraweb using Ajax

The final result is show below. It's not meant to be pretty, but functional and instructive. I'm using the AdventureWorks database shipped with SQL Server 2005. Download code from here

{%URL.DOC