The Thin Client

  • I am working with software from a very large company and on occasion I just have to vent about it. Todays episode is the "Thin Client".

    The Thin Client is a new front end to a change management product that this company produces, which layers over the top of MS Visual Source Safe and provides a lovely GUI that delivers lots of domain specific functionality. Prior to the Thin Client you had to install a thick client on every workstation where you wanted to use the product. This wouldn't be a problem except the product likes (ie almost demands) that the client and server side have to be at the same revision, and that we have client installations where there are large numbers of workerss spread across the country - so co-ordinating a version change becomes horrific. (Please don't say SMS or similar .. the upgrade procedures for this software is a WTF in itself)

    The Thin Client is supposed to alleviate a lot of the problems we have experienced in the past, but in my few days of testing it I have shaken my head at quite a few WTFs . Here is a selection in no particular order:

    • The Thin Client comes in 2 flavors:
      1. A "rich" Thin Client which installs on a workstation and uses IE to host a bunch of ActiveX controls (in a local HTM page) needed to read/write the local file system.
      2. An IIS based Thin Client which uses IIS to deliver the exact same HTM page from the server to IE on the local workstation - so that you still need to have those same ActiveX controls on the workstation in order to read/write the local file system. Thus to use the IIS based system, you still need to manually install the non-IIS Thin Client on every frickin' workstation you want it available at.

    • The change management product (as well as a few others from this company) takes over Port 80 and uses it for its own purposes (and is not visibly configurable). Thus if you want to use IIS on the same machine, then you have to set it to other than port 80 and teach your users all about http and alternate ports. Alternatively for added $$$ you could install IIS on a separate machine.

    • The content that the Thin Client dishes up is a 1190 line page of pure scripting enjoyment (and the IIS version dishes up exactly the same file). 1100 of those lines are VBScript with very little error checking ("on error goto next" anyone?), the other 90 lines are javascript. Why they needed to code the 90 lines in javascript escapes me, unless it was a cut and paste job - but the functionality is well within the realms of what they are already doing with VBScript. Oh, and there are about 27 comments spread throughout the entire file.

    • On my test machine I have IE set up to at least ask me if I want to install new controls when a page opens. So when I first opened the content page IE asked me if I wanted to install the ActiveX controls. Thats good, but then I read the details of the controls it wanted to install: "Name: Control Name is not available" and "Publisher: Unknown publisher". If was paranoid (and not running on a VMware image anyway) I sure wouldn't like to install those controls.

    • My favourite example of code from the content page (with 2 of the 27 comments). Apparently no one has heard of the Right() function:

        For j = 0 to node.childnodes.length-1
         set newNode = node.ChildNodes.Item(j)
         ' Check to see if there are additional sub menus in this item.
         if (newNode.hasChildNodes() = True) Then
       ' Fix to support 10000 folders, rather than the original 10
       strPad = ""
       for tempcount = 1 to 4-len(j)
         strPad = strPad & "0"
       if (len(j) < 1) then
        idx = ""
        idx = strPad & j
       end if

    • The Thin Client is a bit Web 2.0 as you can edit a config file in order to customize the data you see displayed on the content page. For the "rich" Thin Client the config file is stored locally and so can be unique for each workstation. For the IIS version of the Thin Client, there is only 1 config file for all clients (difference of functionality between clients is another WTF), and it is stored on the IIS server machine. But when you use the Thin Client interface to the IIS based system, you can edit and save "a" config file. I say "a" because you are actually editing the config file on the local workstation, not on the server, and when you save the file it gets saved locally. Of course when you go back to the content you are using the config file on the server and you wonder why your changes haven't been taken up. So you go back to editing the config file and .. hang on .. there are my changes .. why aren't I seeing them???? Of course the system doesn't inform you as to which config file you are actually editing.

    • Actually, the instructions for setting up the config file on the IIS based system are to use the Thin Client to edit the local copy of the config file and then manually transfer it to the IIS virtual directory.

    • Part of the config file is to allow you to allocate custom icons to various items displayed by the content page. What I find funny is that the set of icons supplied covers various items from other manufacturers, but doesn't include a full set of icons for this companies own set of equipment.

    • Finally, when you use the Thin Client, you get a nice logon dialog box for the change management system. I was amused to see that it uses Comic Sans for one of its fonts!

  •  wow, activeX controls?  how ...quaint...

    i've dealt with a few of these sorts of activeX based apps before and they have always been a source of wtf's. They usually look like someone's said "this application has to be available on this internet thingy" and so the devs just chuck a vb app into an activeX control and bingo.

    If you need to do stuff like write to the local HDD it sounds like a good winform app that connects to a webservice or makes http requests to your server might be the way to go, using activeX is fraught with security problems.

     + if the ActiveX Controls are hosted on a local HTML page wouldn't it just be easier to have an app do that? 




  • Define 'change management' in this context, please; I'm guessing this is some sort of version control thing?

  • @OzPeter said:

    co-ordinating a version change becomes horrific. (Please don't say SMS or similar .. the upgrade procedures for this software is a WTF in itself)
    I'm entertaining the idea of using text messages to coordinate the upgrade.

    Or Sega Master Systems.

  • @Jake Grey said:

    Define 'change management' in this context, please; I'm guessing this is some sort of version control thing?

    yep. The product effectively treats Visual Source Safe (VSS) as a backend database. It then layers a whole bunch of custom functionality over the top:

    • Network access to the data (which VSS does not do very well at)
    • Grouping the data and providing specific processing functionality for each group type
    • A huge array of security options to control what users can and can't do with each group of data.
    • Audit trail logging of various actions
    • Scripting all over the place (But VBScript only)
    • A event system to fire off scripts at various times
    • Point and click interface that is integrated into the companies main suite of products.

    It all sounds fancy and great, but when you look under the hood it is WTF central in how some of it has been implemented. And that is before you start down the path of bad (if any) QA and struggling tech support (and in all fairness to the tech support people, I think they are extremely overworked)

  •  Use .NET and no touch deployment. The .NET framework can be rolled out using SMS if it's not already on the machines. Then just send the URL to the WinForms smart client and you're laughing. The smart client can then call web services back on the server.

Log in to reply

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.