Skip to content
Snippets Groups Projects
  • Gregory Szorc's avatar
    d059cb669632
    wireprotov2: allow multiple fields to follow revision maps · d059cb669632
    Gregory Szorc authored
    The *data wire protocol commands emit a series of CBOR values.
    Because revision/delta data may be large, their data is emitted
    outside the map as a top-level bytestring value.
    
    Before this commit, we'd emit a single optional bytestring
    value after the revision descriptor map. This got the job done.
    But it was limiting in that we could only send a single field.
    And, it required the consumer to know that the presence of a
    key in the map implied the existence of a following bytestring
    value.
    
    This commit changes the encoding strategy so top-level bytestring
    values in the stream are explicitly denoted in a "fieldsfollowing"
    key. This key contains an array defining what fields that follow
    and the expected size of each field.
    
    By defining things this way, we can easily send N bytestring
    values without any ambiguity about their order. In addition,
    clients only need to know how to parse ``fieldsfollowing`` to
    know if extra values are present.
    
    Because this breaks backwards compatibility, we've bumped the version
    number of the wire protocol version 2 API endpoint.
    
    Differential Revision: https://phab.mercurial-scm.org/D4620
    d059cb669632
    History
    wireprotov2: allow multiple fields to follow revision maps
    Gregory Szorc authored
    The *data wire protocol commands emit a series of CBOR values.
    Because revision/delta data may be large, their data is emitted
    outside the map as a top-level bytestring value.
    
    Before this commit, we'd emit a single optional bytestring
    value after the revision descriptor map. This got the job done.
    But it was limiting in that we could only send a single field.
    And, it required the consumer to know that the presence of a
    key in the map implied the existence of a following bytestring
    value.
    
    This commit changes the encoding strategy so top-level bytestring
    values in the stream are explicitly denoted in a "fieldsfollowing"
    key. This key contains an array defining what fields that follow
    and the expected size of each field.
    
    By defining things this way, we can easily send N bytestring
    values without any ambiguity about their order. In addition,
    clients only need to know how to parse ``fieldsfollowing`` to
    know if extra values are present.
    
    Because this breaks backwards compatibility, we've bumped the version
    number of the wire protocol version 2 API endpoint.
    
    Differential Revision: https://phab.mercurial-scm.org/D4620