Use the Logos Delivery module from an app#312
Conversation
danisharora099
left a comment
danisharora099
left a comment
There was a problem hiding this comment.
Nice integration guide, and it lines up well with the actual module — I checked the documented calls and event shapes against delivery_module_plugin.h at the pinned commit and they match, and the messageReceived data[2] raw-bytes treatment matches what the demo actually does (good, that was a real gotcha on the earlier delivery journey).
A couple of things to fix (inline):
- the doc pins delivery_module to v0.1.1, but the logos-delivery-demo it points at as the "complete reference" is on v0.1.2. Worth aligning so people aren't reading a reference that's a version ahead.
- related:
send()'s payload type changed between those versions (v0.1.1 header issend(QString, QString); the demo passes a QByteArray). The snippet here doesn't say whatpayloadis, and since receive is QByteArray it's easy to get the encoding wrong. - typo: "a working patter" → "pattern".
One thing I couldn't get past: I tried to actually build the demo on an M-series Mac and it dies in the zerokit (RLN) dependency — cargo-vendor gets a 403 from crates.io and zerokit/liblogosdelivery-dev aren't on the logos cachix for aarch64-darwin, so it cold-builds and fails. Same missing-substitute issue I raised on the earlier delivery journey (#37). So I couldn't verify subscribe/send/receive on the live network from this doc — might be worth a prerequisites note about cachix access and pushing aarch64-darwin substitutes.
Non-blocking on the writing; the version/type mismatch is the main thing to sort.
| ```nix | ||
| inputs = { | ||
| logos-module-builder.url = "github:logos-co/logos-module-builder"; | ||
| delivery_module.url = "github:logos-co/logos-delivery-module/v0.1.1"; |
There was a problem hiding this comment.
Heads up: logos-delivery-demo (the "complete reference" linked above) pins this to v0.1.2, not v0.1.1. Worth aligning so the doc and its reference are on the same API. Note the send() payload type differs between them too (see the send step below).
| 1. Send a message. On success, `getString()` returns the request ID; track it through `messageSent` → `messagePropagated` events (or `messageError`): | ||
|
|
||
| ```cpp | ||
| LogosResult r = m_logos->delivery_module.send(contentTopic, payload); |
There was a problem hiding this comment.
Worth stating what payload is. On the pinned v0.1.1 the header is send(QString, QString); the demo (v0.1.2) passes a QByteArray, and messageReceived hands back a QByteArray — easy to get the encoding wrong if the type isn't spelled out.
There was a problem hiding this comment.
Ideally we'd use 0.1.2 already, I just didn't break what I had in #226.
…pi-from-an-app.md Co-authored-by: Danish Arora <35004822+danisharora099@users.noreply.github.com>
weboko
left a comment
weboko
left a comment
There was a problem hiding this comment.
Reviewed the API guide against delivery_module_plugin.h at the pinned v0.1.1 commit. Two unresolved issues from danisharora099 that are blocking:
1. send() payload type must be stated (line 154)
The guide documents send(contentTopic, payload) without spelling out what payload is. On v0.1.1 the signature is send(QString, QString). messageReceived hands back data[2]: QByteArray, so a reader writing code to echo received messages back will naturally try passing a QByteArray to send(), which fails to compile. The snippet needs the type explicit:
// payload must be a QString on v0.1.1
LogosResult r = m_logos->delivery_module.send(contentTopic, payload);2. Version mismatch with linked reference (line 62)
The flake pins delivery_module to v0.1.1, but the doc's "complete reference" (logos-delivery-demo) is on v0.1.2, which has a different send() signature. A reader who opens the demo to understand the pattern will see v0.1.2 calling send(QString, QByteArray) and the doc calling send(QString, QString) — one of them will fail. Either pin the demo to v0.1.1, or update the flake input and the send snippet to v0.1.2 (and update the type annotation accordingly).
igor-sirotin noted in the thread that they intentionally kept v0.1.1 to avoid breaking things from #226, which is fine — but then the demo link and the send type need to match that choice.
4 participants
From: #226