More on transcoding…

Back at the office after one week of relaxing. Have been refining my thoughts on transcoding, an increasingly appealing area (business wise really interesting, and there are technical challenges involved as well), here’s my latest thoughts..

1. Not only relevant for wireless handsets, but very much applicable for the whole desktop market. This is especially true when thinking about JavaScript and DOM rewriting and optimization (my old iBook G3 at home with Safari has issues with several JavaScript heavy sites..).
2. Two main operating modes: URL rewriting and HTTP proxy. URL rewriting could be provided as an ad-hoc solution simply for optimizing a problematic page, whereas the proxy solution has a lot more possibilities (e.g. can be hidden and enforced by a carrier, complete control of download chain, etc.).
3. The Google Web Accelerator does (amongst other things) content prefetching. Traditional proxies work on a request-by-request basis, which is all well for their purpose. Download times could be reduced by doing content analysis and prefetching at the proxy level (e.g. a HTML page is scanned and all images, stylesheets, etc. are downloaded before the client requests them).
4. JavaScript and DOM optimization is still a huge opportunity but very problematic. As a first requirement, a database of browser capabilities is needed. On the mobile side the wurfl project exists to map handset capabilities, but at doesn’t cover browser (DOM) details. Couldn’t find a reasonable DHTML capability resource on the net for traditional browsers, e.g. with DOM compilance levels etc. This could probably be done more-or-less automatically with some JavaScript?

The business opportunities related to transcoding are numerous and range from providing the functionality as a service (à la skweezer) to software licensing, including hybrid models with more daring revenue models (consider e.g. ad replacement &c).

That’s it for today, now I need to get some work done.

/A