As written in the workspace Cargo.toml:
> Note that for better cross-tooling interactions, do not use workspace
dependencies for anything that is not "workspace internal" (e.g.: mostly
dev-dependencies). E.g.: release-plz can’t detect that a dependency has
been
updated in a way warranting a version bump in the dependant if no commit
is
touching a file associated to the crate. It is technically okay to use
that
for "private" (i.e.: not used in the public API) dependencies too, but
we
still want to make follow-up releases to stay up to date with the
community,
even for private dependencies.
Expectation is that release-plz will be able to auto-detect when bumping
dependents is necessary.
Closes#689
ironrdp-pdu contains lots of code that we don’t actually need in other crates such as the virtual channels.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This patch could be split if we introduce a legacy module for the
transition of the few PDUs.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Instead of directly depending on the unmaintained rdp-rs to decompress
RLE tiles dynamically, a few snapshots are saved to test against.
The benefit is to remove a lot of outdated dependencies from our
(developement) dependency graph.
Hiding the lifetimes is making the code less obvious.
That’s not a problem for types that I know about intimately such as
`ReadCursor` or `WriteCursor`, but I actually found myself surprised
more than once when reading code I didn’t authored, discovering later
there was in fact a hidden lifetime parameter.
I expect this problem to be worse for someone not familiar with
our codebase.
I understand this lint is "allow" by default because in some cases
it leads to writing unergonomic ugly code when a type has many generic
lifetimes parameters:
```
TyCtxt<'_, '_, '_>
```
However we _never_ work with more than one generic lifetime parameter in
IronRDP codebase, so it seems to me that the tradeoff towards clarity is
worth it, in our case.
Adds handling for `DR_CORE_SERVER_CLIENTID_CONFIRM` and `DR_CORE_DEVICELIST_ANNOUNCE`/`DR_CORE_DEVICELIST_ANNOUNCE_REQ`.
The next steps in the rdpdr initialization sequence.
