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
