REQ packet format update
From The Open Source Backup Wiki (Amanda, MySQL Backup, BackupPC)
The current format for a REQ packet is:
SERVICE line OPTIONS line one DLE by line
For each DLE line, the first field are space separated and the option are name=value pair, but all name must be known.
We have 2 problems with this format:
1. At each amanda release, it's become harder to parse, new field are added and it's hard to tell if it's the newer format or a previous, we use technique like comparing if it's char or numeric, .... 2. We can't add Application-API property because all option must be known.
To fix 1: All the field must be a name=value pair.
To fix 2: We must differentiate between amanda option and Application-API property.
I propose the following new format:
1- The REQ packet for a NOOP request will not change (We must be compatible with previous release). 2- The SERVICE line will not change (needed to parse a NOOP request). 3- The OPTIONS line will not change (the features must be parsed before we know if the server sent the old or new format. 4- The DLE line will be changed to an xml like syntax as follow: <dle> <program>DUMP|GNUTAR|STAR|APPLICATION</program> <estimate>CLIENT|CALCSIZE|SERVER</estimate> #if fe_xml_estimate <calcsize>NO|YES</calcsize> <backup-program> #if application-api :program=APPLICATION <name>...</name> <property> #can be repeated <name>...</name> <value>...</value> </property> </dumper-program> <disk>...</disk> <diskdevice>...</diskdevice> <level>0..9</level> #can be repeated for sendsize <spindle>...</spindle> <auth>BSD|BSDUDP|BSDTCP|SSH|RSH|KRB4|KRB5</auth> <record>YES|NO</record> <index>YES|NO</index> <exclude> <file>...</file> #can be repeated <list>...</list> #can be repeated <optional>NO|YES</optional> </exclude> <include> <file>...</file> #can be repeated <list>...</list> #can be repeated <optional>NO|YES</optional> </include> <compress>FAST|BEST|NO|CUSTOM <custom-compress-program>...</custom-compress-program> </compress> <encrypt>NO|CUSTOM <custom-encrypt-program>...</custom-encrypt-program> <decrypt-option>...</decrypt-option> </encrypt> <kencrypt>YES|NO</kencrypt> </dle>
This new format will be easier to parse, it will be easy to add new field without breaking compatibility. Adding application-api property will not change the format.
The new packet format will be used only if the client and server support it, the older format will be used otherwise.