- Jon

Good on the guys questioning use-cases and real-world issues with NoSql solutions. It is critical to know core database fundamentals before deciding which persistence solution is right for you.

The problem with skewed blabber like this is other ‘beginners’ will hear this and think you are right; when that is far from the case. Stop blogging and casting crap until you really know. Data is critical in any app these days and you are creating crap in the industry.

BTW, its not ‘negativity’ out there; its experienced people who know their stuff are telling you that you’re spreading bad information.

That used to be true. Recently the IronRuby team wrote a Ruby dbi provider that uses ADO.NET to access SQL server and released it as a gem. As well as a Rack adapter so you can run Rails under IIS7.

More info at the IronRuby site.

http://ironruby.net/Documentation/Real_Ruby_Applications/Rails

The file went from 200MB input video to 500MB (or whatever) output video because you end up with some 5 (or so) copies of the video, each encoded at a different quality level. So by itself, this is not a bad thing. You could simplify by saying each user will only download one of the 5 copies. Users on fast connections will download pieces from the HQ copy, and users on slow connections will download pieces from the LQ copy. (Obviously that’s a simplification, but it’s essentially true.) This might still be a bad thing if you take downstream HTTP caching into consideration (you now have to populate 800 MB of files into each cache instead of 200 MB), but otherwise, the larger file is only going to cost you hard disk space and upload bandwidth, not download bandwidth. (In fact, it should reduce download bandwidth since some users are downloading the LQ version instead of all users downloading the HQ version.)

And if your web server is configured correctly (IIS7 or Apache /w smooth streaming module, properly configured to serve the file as a smooth stream and not as a regular file), and if each downstream HTTP cache is configured correctly, each piece gets downloaded as needed, and is even cached at the intermediate HTTP caches to reduce your local bandwidth load.

Of course, if any minor thing is screwed up, bad things will happen, and the results will be worse than if some minor thing were screwed up with a non-smooth-streaming video. For example, if the player or configuration file points to a URL that resolves to a request for the original file instead of resolving to a request for a piece, then the player will request the whole file, again, and again, and again, every 10 seconds or so. Very bad. Or if the downstream HTTP cache isn’t working correctly, the pieces won’t be cached.

If the cache and the server confuse each other enough, things can get even worse. (I don’t know if this happens with smooth streaming, but it has been known to happen with Windows Update servers talking to Squid caches.) The user requests a chunk of the file, and the Squid cache decides to prefetch the whole file. But since the Squid cache starts at the beginning of the file, it doesn’t get to the chunk requested by the user before the user gives up and tries again (perhaps with a different file at a lower quality setting). And since the request was aborted, the Squid cache throws away the piece that it had downloaded, or something.

In any case, guessing wildly, with no real evidence and only the podcast to go on, I have a strange feeling that you’re encountering the classic issues associated with HTTP partial content requests, where the client asks for a chunk of a resource (the chunking occurring at the HTTP protocol level, i.e. “HTTP GET xyz.wmv bytes 10 through 20). The funny thing is that smooth streaming (as I understand it, which isn’t saying much) isn’t supposed to involve HTTP partial content requests. Instead, the client is supposed to be making a request for the full resource, but the requested resource is supposed to be a chunk of the file (the chunking occurring at the IIS7 ISAPI handler or Apache module handler level, i.e. “HTTP GET xyz.smoothStreaming?start=10&end=20″).

So if it were a technical issue, I would tell you to double-check your server settings and to double-check the player configuration to be sure you were properly serving the file via the smooth streaming server plugin and not trying to serve the file via partial content requests.

On the other hand, since you’ve got a lot of users who insist that somehow the Flash plugin is less evil than the Silverlight plugin (not sure about the logic behind that, but I shouldn’t worry about that), your decision to go back to Flash is completely reasonable, and I’m wasting my time writing this. But it’s Friday night and I’m bored, so no great loss.

Anyway, thanks for reading. (I’ve really got to go get a life…)

xD

They have the while object to database sorted – they don’t care about normalization, it’s all about the performance / user exp…(eg pub product descriptions everyware, or clever cache). The show sounded like none of you had worked within these apps which support complex process and 1000s of concurrent users.

As for alt to SQL – there are many, but as the colleges only every get to SQL, everyone has a hammer, and everything is a nail… I’ve used ODB etc and even spent 10 years using a DB called PICK/UniVerse/IBM U2 – in the 90s I used it to support 1000s user systems on 486 hardward (yes green screen, but sub-sec response)… it used a hash key, untyped and a page database:
http://en.wikipedia.org/wiki/UniVerse
I remember the New York public library used it in the 90s supporting 2000 concurrent users….
.. but SQL is safe and good enough. As long as the bulk 90% of developers only know about SQL – there we’ll stay… Good luck with the MongoDB etc…

Now is it true that Ruby on Rails susported SQL server using only slow ODBC……. that’s another question?… so I can’t mix RoR and .Net easily in my env..