Ok i know there is a site feedback but i know most folks hit the coffehouse all the time.
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 !!
That's still 2 errors too many.
Inconsistent layout problems for me, as I can whinge forever but they key difference for me in old blighty is that it has worked each and every time I have attempted to connect thus far, hence ameliorating my prime dislike of visiting.
I wish I could post from my droid though, or see silverlight video!
@figuerres: hey! Thanks for introducing me to DiscountASP.net--I love that place! Good choice. I think it was you, from about six months ago. PJ
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.
I still miss a way to query episodes, RSS is a pain.
Other then that, it's pretty cool and nippy.
Have you guys got something for dynamically scaling your instances yet?
@figuerres: Yep. And I'm glad they took the live work in progress route rather than the old stoggie 100% lab work then live as is for years route.
For querying, do you mean something like odata? By default, all odata queries hit the database directly and that makes me fear for our database. More apis would be nice though and odata is a fine protocol. It's on the (very long) list but you can use Bing to search the site and get pretty good results.
@Sampy: Not complex queries, but more then 20 episodes would be great. And I'm not going to use bing as a datalayer
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
@Maddus Mattus: The Azure sync stuff breaks our site and I don't like the work arounds.
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.
@Sampy:Agreed, sql sync sux (triggers and stuff). That's why the project I'm working on right now, first replicates the database and then put's sync on the replica.
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
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.