Just wanted to say that so far i have only seen at most 2 errors total on the new site.

that's like 10,000% better than what i was seeing with the old C9 site.

Good Job Guys !!

I wish I could post from my droid though, or see silverlight video!

Our likely method of handling that would be to make the player into just a link to the appropriate video for your device (MP4?) ... then it is full screen. In-page playback on a mobile device doesn't seem ideal to me, although I believe that is what happens with C9 on an iPad when using our HTML 5 player.

Other then that, it's pretty cool and nippy.

Have you guys got something for dynamically scaling your instances yet?

I've got some great ideas I'm working on right now, I hope you will get exited when I show my v1.0.

And if you're scared for your databases, just sync a copy to a new storage account, put an OData service on it, no performance penalty

It adds triggers to tables which causes the row count from Insert/Update statements issued by NHibernate to be greater than one. NHibernate throws an error in this case since it only expected to touch one row and rolls back the transaction. There's a setting to turn off that protection but I can't remember if it's in version 2 of NH or you have to move to 3. Also, I don't want to give up the protection

Also, while syncing would prevent the site from taking a perf hit, it would still show you my schema and I don't really want to do that. The beauty of RSS or ATOM is that it's a static format that we both communicate on. OData would tie both of us together into a schema (the XML blob in the <content> tag) that I now have to support. It's not something I'm against but it's not something I want to walk into without really thinking about it. I'm also worried that Entity Framework couldn't handle the way our database is organized because I use a lot of NH specific features that I don't think EF can handle (any mappings mostly). I could take the middle ground and build one of those metadata based providers but I still don't like that route.

I've toyed with manually implementing the OData protocol (pushing the XML to you myself). It's not that hard. No matter how I implemented it, I would limit the kinds of query operators you could use just like Azure Table Storage does since I like the fact that I control the shape of all the queries done against the database. It forces all code to work against my model and not against my physical database store. If we moved pieces of the data to Table Storage or did something else wacky then the model (entity objects + queries + services) would remain consistent while their implementations would change. Those query objects give me a great list of all the ways that the site needs to bend and shape the data which is a huge boon when building indexes, weighing new features, or even considering some of the wacky back end changes I mentioned above.

Long story: it's a big feature that has to fight other features for space on the schedule. We have talked about adding some of the paging query strings to RSS feeds so you can ask for page 2 and get all items in a list rather than just the top 20. A feed that uses the list extensions and gives you all shows/series/blogs is also an idea we've tossed around. These are much easier to do but still have to fight for schedule time. Use Connect to let us know which ones you like.

I don't need exactly the same schema, I can live with the data that is availible now in RSS, it's just the shortness of pagesize in RSS that's bugging me. The amount of information is perfect, it would be nice to somewhere have a list of Series, Niners, Blogs, Shows and Tags.

And if you are worried about abuse, you could hand out API keys and block anyone that's abusing your layer.

And thanks for taking the time to respond

Hope you will get exited enough when I demo the thing I have in mind to think about it some more