Drexthepimp

So use it wisely, at messaging points, possibly prevent then commands flowing to the db that you can predict would cause errors. The ability to close down ports when failures occur is like a firewall to the database I suppose.

I am playing around with this whole package. It is a very good idea. I suppose i now wonder two questions:

1) How much of this idea was inspired from you working on complicated problems down in the kernel.

2) How much significance could this have implemented down in the kernel, or is it effectively already a tackled problem?

Cheers
Drex

George, I love your enthusiasm, and i think you are really onto something with the CCR. Here is my question though: How do we interact with databases, which are inherently blackbox affairs? Consider this scenario

Function does some calculation, adds a result to the database using a transaction based stored procedure. If we leave the stored procedure working away, and then later on we encounter a rollback, how do we respond to that rollback?

It would seem to me that we have progressed too far in our application. Either we wait to be sure, or we risk being too good at the CCR stage that we force a transaction rollback/Data inconsistency Database Trigger. ie we run 30 threads against the DB, threads 1 and 27 cause a rollback, or are not consistent.

This is just my pet hate at the moment, I daily work with an app that does the following:

func addtoDB(params){ //pseudo code
 addToDB //do SQL one assumes
displayStatusDialogue
}

Now to do multiple dimensional queries, they call the method 30 times, resulting in a dirty 30 dialogues flashing. Admittedly this is rubbish engineering, but it was what got me thinking about the problems of repeatedly hitting the database. Inherently this function assumes success, which is why it frequently crashes [I didn't write it, i just have to use it!]

the idea of ATOMIC database calls seems to be great but closes out the ability to interact with the CCR? Ie the CCR is not allowed to jump in and help the database.

Am I wrong here? I am making wild generalisations about databases, and blind calls to functions, but i see a problem.

It would be interesting to get your feedback, it is great that you are engaging with channel9!

Drex

Ernie Booth wrote:

brian2k1 wrote: Will there be a Part 2 that includes the mentioned trip to the main pc and video splitter setup?

Sorry to say the answer is no.  What information did you want about the setup?

For me I'd like to know how you kept the program running in a kiosk mode while updating? Did the screens go down or was there some backend that could run on a seperate monitor/comp.

The idea of sending the video out over cat5 is nothing new to me, but i would be interested in knowing about the splitters used. My idea is to add areas to the system. Ie different sections can see different presentations, but then since this is just data driven all screens could amalgamate. It would be a seperate box per section, which wouldn't be too much of a problem.

Lastly I would love a few specs on the graphics hardware. I'd be tempted to buy a big box to run all of this, especially when i get the idea that the transitions were poor on perf due to pre beta bits, which could be sped up. And finally i may had a touch screen aspect to this for use on smartboards.

Excellent job. pm me and we can talk. All credit to yourselves of course but i'd love to implement this.

brian2k1 wrote:

Will there be a Part 2 that includes the mentioned trip to the main pc and video splitter setup?

Indeed, for me this will be the best bit. I will build one of these myself with old monitors and redundant cat 5. We are going to see a lot of new entrants to the world of programming being able to build appz like this. data <=> presentation is now as envisioned.

I will build one of these.

Drex

Another excellent interview here where we get to understand where windows meets computer science. I'd love to work on the kernel team. Charles is right when he says the improvements made in the kernel bubble up. More of these. If you need a hand to make them i have a camera and a lot of free time!

PS isn't it about time that we summise how all these various teams are building longhorn...it isn't just Avalon, the kernel team seems fixated. In the virtual server disks they were coy about their whiteboards and longhorn..leads me to suspect that some of their work is going into longhorn too...undo disks, or something along that architectural path.

Wow long rant

Drex

I have to say this guy was a pleasure to watch. He was entertaining and candid. There was a lot of intelligence to what he was saying, and I learned a lot. Dana was an interesting addition. Both guys knew their stuff, and this is exactly what channel 9 should strive to get more of. Who else would talk about the windows kernel with any authority?

I want to see some interviews with the inventor of c#, or the PE file designer. I recently went through winHex for file recovery, and there is a wealth of stuff to learn. If the linux kernell is open source, this is not going to be a major breach:)

Good job lads

Drex