Re: Binary and XML serialization of types

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 24 Jan 2014 00:54:49 -0800 (PST), hanslad@gmail.com wrote:

> In short, I want to develop a client/server library to encode (and decode)
> structures of data(records) and request the data over tcp. 
> Is there a faster way to do this than using streams?

That depends on what you mean here under using streams:

1. Streams for in-memory format transformations

2. Streams as an interface to TCP/IP sockets, e.g. GNAT socket streams.

In the case 1, the alternatives are representation clauses + type
conversion or plain conversion operations. Whatever difference might be, it
is not sufficient.

In the case 2, you should consider using packets instead of a raw octet
stream. Typically you would form an outgoing packet in the memory, using
whatever means (e.g. by a string-mapped stream) and then send the packet
out as a whole. It is especially important to do if you are going to use
NO_DELAY socket option.

> Also, the encoding of a structure could be dependent of where the
> structure is used. Say, the first byte sent over wire tells if the
> "Identity" field in a record should be decoded as a 2 or 4 byte integer.

Is it a custom protocol you are going to invent? Anyway, the protocols
usually deploy some sort of packet header to describe the request and the
body of. The most efficient way is when the body length can be determined
from the header. You read the body into memory and then parse it, e.g.
using a string-mapped stream.

> For me it would be locical to separate all the "wire information" from the
> type information. Today, the binary and xml encoding scheme is defined,
> and I had hope to be able to separate this in different packages.

That is doable.

> What is the locical way to do this?

Deploying OSI model is one way.

I don't know how far up you want to go with XML in breaking the OSI
hierarchy. XML does not make any sense anyway, but considering making it
human-readable as a purpose, you must break it all way up to the
application level, e.g. by exposing names of the fields, having special
representations of the fields, a nasty thing. Otherwise, you use XML sealed
in the presentation layer, by packing everything under one key/value pair.
It is easy to implement, does not make sense either, typical XML.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de