Anyway, it looks like users have to write code to populate Protobuf's generic container at run-time.

I'm not sure that getting it done the faster way development-time-wise offers a good foundation for reworking it later if you decide to shift gears.[/quote]

The fact that you manage all your external (protocol) data using a well-defined IDL, a well-defined wire format, and a tool chain that supports many languages, is a FANTASTIC start on being able to optimize/improve the parts that matter, once you have an actual system where you can measure what matters.

I think the extra code that has to be generated, built, loaded, and run is a bigger deal than some people.[/quote]

Two things:

1. In many languages, you can parse Protobuf descriptions at runtime, and interpret them rather than compile them. Python, for example, can easily do this, as can Javascript and most other truly dynamic languages. The Protobuf in-memory representation even supports transparent version up/down-shifting, by storing unrecognized fields in a "copy-forward" format. This means you can upgrade your protobuf IDL files (which means the network protocol) at runtime. Sometimes, that's quite valuable, and other times, that's probably a bad idea. Network wires are typically slower than the CPUs interpreting the data, so the overhead of interpretation is often not important in a profile of the running system.

2. When you know that CPU cost is important, then you want dedicated marshaling/demarshaling code that is compiled. You could write this code manually. That code would have to be built, debugged, loaded and run, to be able to understand the protocol. Unfortunately, manual marshaling is a very bug-prone way of development. Thus, you can instead generate the code from the IDL files. This doesn't generate appreciably more or worse codtoue than the hand-coded version, but you can be certain that there are no marshaling bugs. Additionally, implementing changes is as simple as re-running "make," rather than, for example, having to update half a dozen different source files that touch the data.

Perhaps it would be possible to use languages' built-in serialization support[/quote]

Then again, perhaps it wouldn't. Each language serializes differently, and almost all languages are too verbose with their "native" serialization for games purposes.
If you want to try this, I suggest trying to find a way to load a Python Pickle into a Java Serialization stream, or perhaps make a DCOM RPC into an Erlang port. I'd be very interested in hearing how that goes!

How is built-in serialization verbose?[/quote]

By including too much information compared to what you can get away with when you have lots of domain specific knowledge.

I found getting away from a web-based front end to be liberating. [/quote]

Is this the same web-based front end that you last year suggested would be much better than everything that had come before it?
You may want to go back and re-review the discussion that was had about that a year or two ago. If I remember right, a lot of the same information that's in this thread was provided at that time, too.