Re: Messaging Frameworks in Embedded C/C++ / Serialization
bwood wrote:
kanze wrote:
bwood wrote:
James Kanze wrote:
[...]
In such cases, I'll usually invent a very, very
simple data description language. Something, say, that I can
parse with about ten lines of AWK.
Part of what I mean by using the word decent above is that the
process of writing send/receive functions for user defined
types should be automated.
Agreed. But that's pretty simple, since what I'd do is generate
a class type with the necessary serialization for starters.
If programmers are responsible for those functions, it is
easier to write tools like this, but it is error prone to have
to keep the send/receive functions in sync with changes made
to the type.
They don't. Any changes made to the type are made in the data
description language you've invented, and the various scripts
then regenerate all of the necessary code.
That is kind of shifting things around though. Ideally I think
there should be one place to make changes to the type.
There is only one place: your data description.
It seems like your approach means duplicating some information
and making sure you keep the data description code in sync
with your C++ code.
Well, the information IS duplicated, in the same sense as
information is duplicated in the object file and the C++ source.
Your make file (or whatever you are using) keeps the C++ code in
sync. You never touch it.
Versioning can be a pain in such cases, but the tools I'm
familiar with don't help much there either; in fact, it's
sometimes easier to handle it in a protocol you design yourself.
I think almost everyone agrees supporting multiple versions of
software simultaneously is a hard problem. Here are a few
thoughts on the subject.
Often a new version of a server is required to support multiple
versions of ambassadors/clients. In the following example I'll
consider a class called Account through 4 releases. The class
will only need to be changed between releases 1.2 and 1.3.
release
1.1 1.2 1.3 1.4
----------------------------------------------------------------
class name Account Account Account_13 Account_13
The class name incorporates the release in which it was last
changed. Let's say that the 1.3 version of the server is required
to support 1.1 clients. To do this the server is built with both
the Account and Account_13 definitions.
I've usually seen namespaces used for this. And the version
number (for Account) integrated into the namespace from the
start.
When only additions to Account are needed between releases,
the software might be structured like this
AccountBase
|
Account
|
Account_13
If members need to be relocated out of Account in 1.3, the
hierarchy might be
AccountBase
/ \
Account Account_13
I rather prefer replacing the old version of Account with a
fassade class, which forwards to the new version, mapping when
necessary. (Given the data description language, it isn't too
difficult to write a short program which generates the basic
fassade; you then manually modify it for the cases where special
handling is necessary.)
In either case, the 1.3 server may use polymorphism and
accomplish what is needed pretty simply. When working
with a 1.1 ambassador, it produces 1.1 data by executing
what originally was 1.1 code.
We're using a somewhat simpler system here: each field has a
default value, and only fields with other than the default value
are transmitted, each field being transmitted with a field id.
Clients ignore fields that they've never heard up, and we ensure
that the server has the latest version. So adding a field is
trivial, just update the server first. Older clients won't send
the new field, and will ignore it when it is notified.
As long as there is a central server, and you can be sure that
it has the latest version, the problem isn't too difficult. The
fun comes when you have a distributed system, with several
different servers, and the server might be running different
versions. So the client also has to be able to handle different
versions, and maybe indicate that some specific functionality
isn't available for the Account served from one of the servers.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]