Quote from: 2112 on November 02, 2012, 03:35:20 PM

Quote from: MPOE-PR on November 02, 2012, 03:24:39 PM

MPEx sort-of started from there, but changes kept being brought to the point what we use now is barely reminiscent.

Can you describe those changes in a paragraph or two? Was there something missing? I'm actualy more interested in the motivation for changes than the actual software changes.

I'd like to understand motives, if possible. Technical details I would consider secondary.

Well let's start with an example comparison:

Quote

8=FIX.4.2 | 9=178 | 35=8 | 49=PHLX | 56=PERS | 52=20071123-05:30:00.000 | 11=ATOMNOCCC9990900 | 20=3 | 150=E | 39=E | 55=MSFT | 167=CS | 54=1 | 38=15 | 40=2 | 44=15 | 58=PHLX EQUITY TESTING | 59=0 | 47=C | 32=0 | 31=0 | 151=15 | 14=0 | 6=0 | 10=128 |

vs

Quote

DIVIDEND|B.MPCD.A|35000000000|350000

FIX uses predefined tags, which then receive values. This is great if a majority of messages will use only a small fraction of available tags, because it saves some space. However, if most messages use most tags it quickly becomes redundant. In a more FIX-ish approach the above MPEx string would have read

Quote

1=DIVIDEND|2=B.MPCD.A|3=35000000000|6=350000]

or something like that. Since the vast majority of messages would refer a type of action (1) and a MPSIC (2), most would include a value (3) and few use more than 4-5 fields, the simplified scheme seems preferable.

The FIX style would also allow for the mixing of tags, something MPEx does not tolerate. The advantage of something like that seems not worth the mention however (again on account of the short messages).

FIX uses checksums and some braindamaged signature implementation. We've dispensed with all that, relying instead on GPG clearsign and armored encrypt, which actually seem a much better solution.

You can check out the FAQ for more details on the MPEx protocol.