https://bugs.kde.org/show_bug.cgi?id=525027
Bug ID: 525027
Summary: Conversations D-Bus API gives a client no way to know
when all thread heads have been delivered
Classification: Applications
Product: kdeconnect
Version First 26.08.0
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: common
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
requestAllConversationThreads() starts a stream: the phone sends thread heads
and they arrive
as conversationCreated and conversationUpdated signals, at four to five per
second here, so a
device with 1731 threads takes about six minutes to enumerate. What the
interface does not
provide is any way to learn that the stream has finished. There is no
completion signal, and
no property carrying the total number of threads the phone holds, so a client
has nothing to
compare its partial view against.
The result is that every client has to invent the same heuristic: poll
activeConversations(),
watch for the count to stop growing, wait some quiet period, and then decide
the enumeration
is probably complete. That is a guess, not an answer. Set the quiet period too
short and you
silently truncate; set it too long and every query pays for it.
The consequence that matters is not performance but correctness. When a client
searches SMS
and finds nothing, it cannot distinguish "there is no such message" from "the
threads holding
it had not arrived yet". For a search feature those two are opposite answers.
Our client works
around it by refusing to give a plain result at all: every response carries a
coverage field
with one of heads_only, partial or complete, so the caller at least knows which
of the two
situations it is looking at. That is the honest thing to do, but it is a
workaround for
something the daemon already knows and does not expose.
Per conversation the situation is fine: conversationLoaded tells a client that
one thread is
done, and that signal is exactly what is needed. The gap is only one level up,
at the point
where all threads have been enumerated.
What would help, in rough order of preference:
- a signal such as allConversationThreadsDelivered() emitted when the phone has
finished
sending heads for a requestAllConversationThreads() call
- or a property exposing the total number of conversation threads on the
device, so a client
can compare it against what it has received
- or a completion flag on the existing signals marking the last one of a batch
Any one of the three removes the heuristic. The first is the cleanest because
it mirrors
conversationLoaded and needs no polling at all.
This is a design gap rather than a defect, filed as a companion to bugs 525021
and 525025,
which came out of the same work on a third party client against this interface.
Environment:
openSUSE Tumbleweed, kernel 7.2.0, Wayland session
kdeconnect-kde 26.08.0
Plasma 6.7.4, Qt 6.11.2, KF6 6.29.0
Phone: Volla Phone X23, Android, 1731 SMS threads
--
You are receiving this mail because:
You are watching all bug changes.
