Re: [pbs-devel] [RFC v2 pxar 09/36] encoder: add payload advance capability

["Fabian Grünbichler" <f.gruenbichler@proxmox.com>]

On March 11, 2024 3:22 pm, Christian Ebner wrote:
>> On 11.03.2024 14:22 CET Fabian Grünbichler <f.gruenbichler@proxmox.com> wrote:
>> 
>> 
>> so isn't this in fact a PayloadOffset then (like it is returned as in
>> the corresponding getter)? and isn't the size then actually another
>> offset as well? would maybe make it easier to avoid "holding it wrong"
>> (i.e., passing in some other u64), or at least, force to wrap it in
>> PayloadOffset which hopefully entails double-checking that that makes
>> sense ;)
>> 
> 
> No, this is actually the size to advance the position of the payload stream by
> when injecting reused chunks, so the caller will pass the total size of the
> injected chunks.

what I mean is - when you read this you encode it as PayloadOffset. when
you advance it to skip (ahead) to a certain offset, it's now a regular
u64.

I know the (only) input here (at the moment!) is chunk size(s), but what
effectively happens is you tell the encoder "advance by offset X", so we
might as well mark it as such in the interface, and force callers to
think "hey, does it make sense to cast/wrap the u64 I have here as an
offset in payload context?" (which it does when we want to let the
encoder skip ahead by X chunks)

> I was thinking of adding the chunks themself as parameters, this would however
> require to expose that type to the pxar crate, so I opted for keeping this as
> unsigned integer. Maybe I should construct a dedicated type just for this?

I think it's fine to just pass the value by which we want to advance, I
just wonder whether it doesn't make sense to refer to it as
PayloadOffset across the board and internally, to make it clear at the
pxar <-> rest interface what meaning this u64 has, to avoid confusing it
with the other (wrapped or unwrapped) u64 values we have all around.