You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently if you only upload 1 trace, we auto-generate its opposite in the sequence diagram (e.g., you upload client, qvis generates server)
This is done by doing a full copy of the original trace and then manually swapping packet_sent for packet_received and vice versa.
This is however quite wasteful, especially for large traces, and swapping sent/received is a bit confusing for several users if they click on the squares to watch event details. Additionally, we default to showing the client-side event in the detail popup, causing the generated qlog to show up if you upload a server-side trace instead of the server-side qlog, which is even more confusing.
I did this approach initially to make it easier to re-use code across single-trace and multi-trace setups. However, adding a bit of special code for single-trace scenarios should work too.
I do have a faint recollection that this was tried initially but was too difficult for some reason, so best to do some proper analysis before starting this...
The text was updated successfully, but these errors were encountered:
Currently if you only upload 1 trace, we auto-generate its opposite in the sequence diagram (e.g., you upload client, qvis generates server)
This is done by doing a full copy of the original trace and then manually swapping
packet_sent
forpacket_received
and vice versa.This is however quite wasteful, especially for large traces, and swapping sent/received is a bit confusing for several users if they click on the squares to watch event details. Additionally, we default to showing the client-side event in the detail popup, causing the generated qlog to show up if you upload a server-side trace instead of the server-side qlog, which is even more confusing.
I did this approach initially to make it easier to re-use code across single-trace and multi-trace setups. However, adding a bit of special code for single-trace scenarios should work too.
I do have a faint recollection that this was tried initially but was too difficult for some reason, so best to do some proper analysis before starting this...
The text was updated successfully, but these errors were encountered: