Ruminati

You need to get it all working and then you should find that it all just works.

He really said that. In a patronising tone, no less.

Before you can know whether someone is wrong, you have to shut up and listen to what they’re saying… unless you have all the answers. In that case, an idea coming from someone else must be wrong because if it were right you would have thought of it.

This rather enviable situation means you need listen to others only until you work out which of your ideas they are talking about. As soon as you match their rambling to one of your own thoughts you can stop listening. Often you can save everybody a lot of time by interrupting with a parade of your own succinct yet awesomely complete understanding of the subject.

Of course, if you can’t match their rambling to your own thoughts then clearly they are spouting rubbish. You are practically obliged to interrupt, whether or not they were talking to you.

Curiously, people are completely ungrateful about the gift of your correction. They don't seem to grasp that you are protecting them from making fools of themselves, and are apparently oblivious that their poorly considered twittering interrupts your thoughts.

The bad news

Unclosed listener sockets can hang a crashed application or service, prevent it from exiting. Listener sockets are just as likely to be started on their own threads. This makes the code a lot more straightforward — with the listener on its own thread you can use blocking read — but careful design is required to guarantee an exception can be trapped.

Remoting is fragile as hell. Remoting fans won't like that as a statement. They'll go on about how clever it all is. I know it's clever, but the fact is that a connection from anything other than a remoting client will cause serialization errors. So will a connection from a remoting client with out of date classes. These exceptions occur in framework code. To catch them you need a global exception handler, otherwise it knocks out your application. Global exception handling doesn't work properly in a Windows Service, which makes remoting basically useless outside of a rigorously controlled environment.

Remoting also has problems with firewalls, not to mention routing. None of these problems is insurmountable, but the solutions involve extensive reconfiguration of the environment. There is an underpinning expectation that the mountain will come to Mohammed, which is not reasonable. Remoting is also very sensitive to intermittent connections. The remoting framework doesn't throw an exception, it goes catatonic. I think this is because the framework waits patiently for a request that never comes, like a jilted lover sitting by the phone in some horrible country and western ballad, and so I conclude that remoting is unacceptably sensitive to its environment.

UDP discovery seems like a good idea but works poorly or not at all in an internetworked world, due to firewalls and routing issues.

The good news

No-config may not be practical but low-config certainly is. Only one application setting is required: the name of the configuration host. From there you can bootstrap everything else.

Low-config won't protect you from the fragility of remoting, but the solution here is equally simple: don't use remoting. Use web services instead. Web services have the following advantages over remoting.

• They work through most firewalls.
• They are very tolerant of networks that suffer frequent brief dropouts.
• They are tolerant of runtime changes in protocol configuration, such as may happen when a notebook is hibernated at work and taken home, and wakes up on a different network.
• To consume a web service requires only sockets and XML parsing, so they can be used to bridge platforms.

Threads are another thing that can catch the unwary, but it's easy to make them safer: just mark them as background threads. When you do this, shutting down the main thread forces all background threads to exit.

Some people frown on the use of thread pool threads on the basis that you might run out of them because the thread pool is finite. This is pretty silly if you ask me. There's a limit to the number of threads the underpinning operating system can support. Attempting to create a thread can fail. Attempting to get one from the pool never fails. Sometimes it blocks until a thread becomes available, but it never fails.

It occurs to me that remoting over HTTP will certainly go through firewalls and may not suffer so much from erratic connectivity, since HTTP is intrinsically stateless. But this still won't protect you from (de)serialisation problems.

The way remoting is used at work, the objects are there basically to provide context for function calls. This context is all client-generated and might just as easily be client maintained and passed to the server as a parameter. Ultimately an object method invocation is basically a function call with a hidden extra parameter that points at a struct. If you make the struct explicit and keep it at the client you can use web services to get all the benefits of remoting without all the infrastructure.

For that matter, you are also making better use of the network as a distributed computer, since you have distributed lifecycle management and transient storage among the workstations. In high volume scenarios this would take considerable load off the server.

The ribbon is natty. Most of the time I think it's quite a good idea. Then, when I can't find something I get really annoyed because they took away the menus. I don't see why that was necessary. Menus and the ribbon serve exactly the same purpose in ultimately similar ways. The ribbon is great until you can't find something.

You'd think, at that point, that the natural thing to do is invoke help and find out where, on the ribbon bar, the sought after menu item lurks. I certainly thought so. "Master document", I typed. Nothing. "Subdocument" and then various permutations on these. Nada.

In fact you click the View ribbon tab, then you put the document in outline mode, then suddenly you have a group titled "Master Document" to play with. Why then, I ask, does "master document" produce nothing in help? Even, I might add, if you expand the search to include content from the web.

Eventually I used Google, which found it in one go. Out of morbid curiosity I tried Microsoft Live Search - which did find the same article in one go. Someone should tell the Office team (or whoever's responsible for Office help).

Pathetic.

 On the bright side, at least it's pathetic without a paperclip.