Archive for April, 2009
Singing the Praises of Microsoft?!
Posted by Jay Charles | Filed under Rants and Not-So-Rants
It’s not all that often I have anything great to say about Microsoft… but today brought a particularly good experience. Given that I’m pretty quick to jump on the soap box and start complaining when something is wrong, it seems only fair to sing praises when something is right.
Today, I was forced to install Service Pack 1 to the Vista machine on which I do most of my development work. I typically don’t install service packs unless it’s absolutely necessary (SP installs usually = downtime fixing things), but since SP1 is a requirement for Adobe CS4 (I’ll complain about that later), installing the service pack became necessary evil.
My first attempt at installing was the failure I expected… Windows made it to stage 3 of the installation, and then stalled at about 75%. Life was bad, and I had visions of never being able to use that machine again (I’m being dramatic there… one can always reformat and start over).
I went to the Microsoft site looking for help, and after going through all of the KB articles and not finding the fix, I submitted a support request. Quite honestly, I was expecting to find that support would be an endless chain of emails with people who didn’t understand the problem. To my surprise (and to my pleasure), I was immediately directed into a chat session with a real, live support person. Even more to my surprise, the support tech initiated an “Easy Care” session, jumped on to my desktop, and fixed the problem for me. Really… no fooling… the guy just fixed it, and his manager called me half an hour later to make sure everything was working.
I am simply floored by the experience. Whoever is running the show at MS support is really on their game today.
I thought I’d never say this, but it appears that Adobe could learn a few things from Microsoft. Seems a bit backward when I can get immediate, one-to-one support with a well qualified tech for a $300 operating system, but I can’t even get an email response to support requests for $4500 server software.
FMS and its “built-in” HTTP support: First Impressions
Posted by Jay Charles | Filed under Flash Platform
Flash Media Server version 3.5 sports some new HTTP features that, on the surface, are really sort of exciting. The idea that a single deployment might support Flash video over both RTMP and HTTP makes my inner geek smile.
FMS 3.5 came out a few months ago, but due to workload and lifeload, I just hadn’t had time to test out the HTTP goodies. Last week, one of my clients came to me with a challenge that required diving headlong into FMS’s HTTP support.
The trouble my client was having was that he couldn’t find how to enable HTTP support for FMS Vhosts. After a short investigation I found the cause of the trouble… there is no built-in support for consuming HTTP resources from a Vhost.
Out of the box HTTP support in FMS works like this:
- Upon installation, FMS installs Apache 2.2, configured to bind to port 8134
- A “webroot” folder is created in the FMS installation directory
- FMS handles all requests for both RTMP and HTTP
- When FMS encounters an HTTP request, it proxies that request to port 8134
- Apache goes looking for a file in the default webroot directory
… that’s it. Once FMS hands off to Apache, FMS is out of the picture. It’s then up to Apache to do the rest of the job.
Now, if your FMS/Apache deployment uses all of the default configs, and if you don’t need to support HTTP for multiple Vhosts or support for serving files over HTTP from the same location from which you serve RTMP (a la HTTP’ing files from your FMS Vhost directory structure), this arrangement works quite nicely. You dump your files into the preconfigured webroot (as well as into the director you’ll use for serving via RTMP), and you’re done.
In my client’s case (and in the case of just about everyone else I’ve built FMS apps for), multiple Vhosts and/or delivering media files from application directories (without duplicate files elsewhere) are requirements… and in this particular case, the only option was to enable Vhost support on the Apache FMS installed.
I like to think of myself as a fairly smart guy, and I’m reasonably quick when it comes to picking up on new things… but administering Apache is an area of broad scope. After two days of doc reading, forum searching, and some help from folks on the FMS Listserv , I found my way through to what needs to be done. The first half of the job involves setting up a corresponding Vhost on Apache for each FMS Vhost (or creating a wildcard Vhost on Apache… that’s the route I took) using mod_vhost_alias, and the second half is to create rewrite rules to translate HTTP URL’s to the application directory structure within the FMS Adaptor, using mod_rewite.
Right now, anyone who has previous experience with Apache is thinking something along the lines of “well duh Jay, I could have told you that”, but having never worked with Apache in the past, it was a challenge to get it done. That’s not a complaint, but it does raise a complaint…
Now that FMS is being advertised as having “HTTP delivery support” included, many of my clients are going to expect me to get it working regardless of the app structure (after all, Apache is now “part of FMS” so to speak). Non technical people (you know… the ones that are usually writing the $4500 check for FMS) are apt to assume that since the marketing speak used on the FMS product page simply says “HTTP delivery support” it means HTTP support is native to FMS and FMS can serve up all of your media over both HTTP and RTMP. That’s not really the case. What FMS can do is proxy requests to an httpd server… but unless you’re using the default httpd configuration and putting your files into the default webroot as set up by FMS, you’re on your own to configure Apache to handle the requests as you need them to.
My personal take on this is as follows; If Adobe is going to market FMS as supporting HTTP delivery, there ought to be some tighter integration between FMS and the httpd server. Of course, there’s no way the FMS engineers can provide automatic support in all situations, but it seems to me that the included httpd server (in this case, Apache) could be/should be pre-configured to handle what FMS developers have come to know as common configurations (i.e the typical application/streams/instance/file.xxx structure FMS creates when recording streams). Even better would be extending FMS to support making Apache configuration changes a task that would be handled through the FMS admin console (that would actually be pretty sweet… a bit of GUI that lets an FMS admin associate directories in the FMS adaptor structure with HTTP URL’s).
Barring that, I really think the point about HTTP support should be removed from the FMS product page, or at very least qualified with a description of what can and can’t be done before you need to get your hands dirty with Apache configuration changes.