On 14/10/16 11:59, A. Soroka wrote:
6/ Packets of change.
To have 4 (label a patch with reversible) and 5 (the version details), there
needs to be somewhere to put the information. Having it in the patch itself
means that the whole unit can be stored in a file. If it is in the protocol,
like HTTP for E-tags then the information becomes separated. That is not to
say that it can't also be in the protocol but it needs support in the data
As long as the sort of information about which we are thinking makes sense on a
per-transaction basis, that could be as I suggest above, as "metadata" on BEGIN.
So a patch packet for a single transaction:
where QA and QD are "quad add" "quad delete", and "PA" "PD" are "add prefix" and
I'm suggesting something more like:
TB PARENT <UUID> VERSION <UUID> REVERSIBLE
TC H <sha1sum>
Or even just positionally
TB <UUID> <UUID> REVERSIBLE
An "HTTP header"-like form (key-value lines) would be better because it
is an open design where new header fields can be put in as needed.
(e.g. "Author", "Date", "Signed-off-by").
It could be done as a different style, maybe identical to HTTP, so the
patch specific parsing begins at the first TB, or include a blank line
or marker like "----". Or the header could reuse the same parsing
tokens, though values may end up in strings for grouping more often.