Serialization is the process of taking an object, and streaming the contents of that object into a file, or communications channel, or any other form of media; and then rebuilding that object on the other side, so that it takes up the exact same representation as it did on the sender side. Think of it as a Star Trek teleportation device, but for data objects - the data objects being represenations of invoices, computer commands, telephone extensions or more complex forms of data.
Delphi has this for TComponent objects, but not for anything else. So I've had to build a complete serialization layer, using such fancy classes and interfaces such as ISerializable, TSerializeBuffer, TSerializeObjectHelperRTTI, TSerializeObjectHelperNoElements, TXmlInterfaceSerializer (which isn't complete), all available through functions like SerializeObject, UnserializeObject and PeekSerializedClassName, through heavy use of variants and run-time type information.
To further agonize over this, this is but one part of the problem. We're building server flashes into our system, meaning that a specific information-gathering part of our programs can run in three different ways: 1) through normal execution, 2) threaded execution to provide application responsiveness even though a task is executing, and 3) a server-based remote object call, placing the heavy burden on the server instead of the client.
I don't know how this happened, but somehow, I find myself building a complete client/server-based remoting layer into a language that doesn't have it; and interfacing that remoting layer with dynamic fail-over to local methods in case the link goes down.
Isn't this what the wizards at Sun or Microsoft are supposed to be doing?