Why a thin client?

Ease of development

I think I must be a lazy person, or at least a person with a slightly strained posture. I don't like being shut away in another room with the desktop and an MVP, I'm much more comfortable sitting/lying on the sofa with a couple of cats trying to sit on the laptop.

Half the time, sitting at a desk just isn't necessary, I've got a client that runs on my laptop and connects to the server and shows me the ui I'm working on. Sure, when it comes to playback issues then the desk is needed.

Potential for rich features

The MediaMVP ships with 16MB of user accessible memory, the kernel takes up a couple of MB, busybox another couple. There's not much memory left for fitting in features such as image displays.

Multimedia playback

The MVP hardware only deals with MPEG audio and video (well and PCM!). In order to playback other types of media you'd need a server anyway to perform the transcoding.

Thin Client is fast

Actually it is, it's just the implementation in the Hauppauge software doesn't make optimisations that would yield a stunning speedup. For example, to talk to a Hauppauge dongle you have to send the entire screen: sending partial updates doesn't always work. If you've got a complex display that's a lot of data to be sent when you're just walking through a menu which would probably update only 1/10th (probably smaller) of the screen.

A year or so ago I wrote my own bit of code that could talk the Hauppauge protocols: I wanted to see whether I was backing a dead horse going down the thin client route, I saw display updates that fitted within a single ethernet packet, that's when I realised that it's better to perform the work on the server rather the client.

Not just the MVP...

The actual UI generation and interaction is independent of the protocols used, thus once a server is written if another platform comes along the whole system can easily support the new device.

28/5/2006 Contact: dom /at/ suborbital /dot/ org /dot/ uk
sourceforge.net