Right, so i started thinking I'm doing too many trips, because the client and server could just sign their packages. But that doesn't actually prove anything. After all, someone could have just connected to a server, received their package and then used it to respond to someone connecting to them. That way they'd be pretending to be the other server. The package would be validly signed but not prove the servers identity. Basically we do still need the random phrase challenges from both sides
This does bring up the whole Man-In-The-Middle problem. I could still simply become a proxy between two peers. Not wanting any central service for registering, I'll probably just go with adding the IP in both the client and server packets. That way we can check that the message originates from the same IP we're talking to.
I was looking at the MacMini and were I not only invested in using my chipped Xbox with XMBC, I'd seriously consider a MacMini as my Media Center. I mean it's perfect:
Has DVI out, easily connectable to my HDTV for high res output
Has a DVD player and a DVD drive
Is tiny
Is ultra quiet
Runs iTunes, and all things XMBC considered, iTunes is still the best music player
Has BlueTooth for all sorts of remote control options, from Mouse/Keyboard to PamOS to Phone
Easily customized via Applescript or perl or even just writing an app in C++, Java, C# (Mono)
Easily networked
Affordable
Ho hum. But my money is heavily invested in other hobbies already, so this one will have to wait until i can rationalize replace
Lately I've been trying to do a lot more design before sitting down and cranking out code, thinking that it would cut down on some of the iterative revisioning I see being the staple of programming. But how to do that design without having to do it all over again once the coding starts.
UML is cool and all, but I find it better for explaining things to others, after the design has progressed, than for designing objects. It also doesn't let me express C# syntax properly and I still have to transcribe everything by hand into the IDE later on and the link between the two is lost.
I could write out the object design as text, describing inheritance, members, etc. That usually works best for me, but then I still have got to transcribe it into the IDE and again the link between design and implementation is lost.
I briefly played with code generation, creating an XML schema to define the classes, then generating code from that. Still suffers from the design/implementation disconnect. As soon as the generation is done, and i fill in the code, they diverge. I considered writing the Code Generator to be able to parse the code back in, update the XML and then be able to generate any changed code from that.
I think I've stumbled across a better approach though. Integrating straight into VS.NET and using the CodeModel that the IDE builds on the source files, to alter and design classes. Everything stays in the native code format, but i can still tweak it without touching code.
My current design goal is an Add-in that mimics the Object Browser, but allows you to alter the classes on the fly, as well as add new classes, members, etc. Then build onto it a way to create "code templates" so that you can autogenerate more than just method stubs, such as creating fields with accessors. Eventually you have a Class Editor with a plug-in system for code generation templates. If i then add a way to annotate the design, probably by extending the XML doc format already in there, i have a nice system for keeping design and implementation together.
So far, my add-in can mimic the Object pane of the Object Browser. Tonight I hope to add the Member pane functionality, then comes Adding new classes/members.
Back in the day (read: 1991ish) I thought that programming GUIs must have at least as sophisticated an interface as the GUIs themselves. Shortly thereafter I got to spend a day with a color Next Slab. That short exposure to the Next Interface Builder seemed to prove that supposition.
Sure, it was only a couple of hours, and really, I wasn't in the drivers side of the demonstration, but watching a word processor being built in an hour or two with lots of visual drag and drop was amazing. And this wasn't just a Form editor, but you actually visually connected visual components to code components. Cool stuff. Unfortunately, NeXT didn't make it (ok, a good bit of NeXT tech is in Mac OS X). Nonetheless, an expectation was set.
So I tried my hand at MPW (Macintosh Programmers Workshop) under Mac OS 7.1. Ugh. Not what i'd call elegant. And visual? No chance. I tried ThinkC.. A little easier to understand, but still all sorts of calls to toolkits originally written in Pascal, and nothing visual about that development.
Then came the new kid in Mac Development, Metrowerks. In its Codewarrior development suite there was a tool called Powerplant. It helped build the interface and create code stubs to fill in. It was ok at the time, and in many ways, it's what's now standard in most form builders. But still, it seemed like a lot of typing to do something inherently visual
Still pining for NeXT, i became a BeBox developer as soon as it became available for sale. I was full of that kool-aid drinking enthusiasm that comes naturally to any Mac Geek. Everything about BeBox screamed "technically superior". The community was full of people whose hopes and dreams were used to being crushed: Mac Developers, NeXT developers, Amiga programmers. I even saw a guy with a Taligent Pink T-shirt at the developer conference.
The one thing that didn't enter my mind when thinking BeBox was "immature technology". And it was. Very cool, with much potential, but the OS was still being written as people started doing development of application. Lots of things changed rather radically under the hood. The edition of Codewarrior that came with it didn't even have Powerplant. There were stories about and Interface Builder coming, but when it came it wasn't revolutionary in any sense of the word.
Long story short: Development under BeOS was no more advanced than any other OS and I moved on from the platform after realizing that it wasn't going to make it, especially when Apple didn't buy BeOS and bought NeXT instead.
Last couple of years I've spent most of my time working on the server side, saying "Bah!" to non-browser GUIs.
Now I'm back in GUI land, this time with C# under Visual Studio .NET and, all things considered, it is probably one of the best out there. Even if it is only incrementally more advanced than other suites for GUI development I've worked with. It's fun (even lacking Emacs mode) and quite productive.
But I still think that the potential of Visual Programming has not even had it's surface scratched. Ho hum.