Swiften Question about payload parsing

--===============1103018386==
Content-Type: multipart/alternative; boundary="0000000000000918aa05bca7799f"

--0000000000000918aa05bca7799f
Content-Type: text/plain; charset="UTF-8"

Hello everyone

Today I have question, specific to Swiften. So maybe Kevin could answer
this ;-)?

My omemo implementation works as expected now. But from an architecture or
performance point of view, it is not really smart implemented.

The LurchAdapter Class (which handles all the message parsing and
forwarding to lurch [1]) catches each incoming Swift::Message stanza. This
stanza will be serialized to a std::string [2]. Just to be able to parse
out the <items> or the <encrypted> xml part within a message [3]. This part
will then be forwarded to lurch, which does the real work on it.

While this works, especially on an embedded device (mobile phone) this has
an huge resource impact. I tried to get into swiften in more depth and
tried to implement a class, derived from Swift::Payload, which should do
the parsing for the 'items' or 'encrypted' payload part. But I don't know
how to integrate it in the overall parsing of incoming stanzas. My target
would be to have it somehow integrated in a derived class of Swift::Message
which could provide me with
std::string Message::getItems()
std::string Message::getEncrypted()

Any hints on how to do this, or any clever alternatives are appreciated :-).

Best regards
George

[1] https://github.com/gkdr/lurch/
[2]
https://github.com/geobra/harbour-shmoose/blob/80da28bc87aa0fb3ed600db9ba6cb2b8e18f5500/source/xep/omemo/LurchAdapter.cpp#L448
[3] https://xmpp.org/extensions/xep-0384.html

--0000000000000918aa05bca7799f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello everyone<br></div><div><br></div><div>Today I h=
ave question, specific to Swiften. So maybe Kevin could answer this ;-)?<br=
></div><div><br></div><div>My omemo implementation works as expected now. B=
ut from an architecture or performance point of view, it is not really smar=
t implemented.</div><div><br></div><div>The LurchAdapter Class (which handl=
es all the message parsing and forwarding to lurch [1]) catches each incomi=
ng Swift::Message stanza. This stanza will be serialized to a std::string [=
2]. Just to be able to parse out the &lt;items&gt; or the &lt;encrypted&gt;=
 xml part within a message [3]. This part will then be forwarded to lurch, =
which does the real work on it.<br></div><div><br></div><div>While this wor=
ks, especially on an embedded device (mobile phone) this has an huge resour=
ce impact. I tried to get into swiften in more depth and tried to implement=
 a class, derived from Swift::Payload, which should do the parsing for the =
&#39;items&#39; or &#39;encrypted&#39; payload part. But I don&#39;t know h=
ow to integrate it in the overall parsing of incoming stanzas. My target wo=
uld be to have it somehow integrated in a derived class of Swift::Message w=
hich could provide me with <br></div><div>std::string Message::getItems()</=
div><div>std::string Message::getEncrypted()<br></div><div><br></div><div>A=
ny hints on how to do this, or any clever alternatives are appreciated :-).=
<br></div><div><br></div><div>Best regards</div><div>George<br></div><div><=
br></div><div>[1] <a href=3D"https://github.com/gkdr/lurch/">https://github=
.com/gkdr/lurch/</a></div><div>[2] <a href=3D"https://github.com/geobra/har=
bour-shmoose/blob/80da28bc87aa0fb3ed600db9ba6cb2b8e18f5500/source/xep/omemo=
/LurchAdapter.cpp#L448">https://github.com/geobra/harbour-shmoose/blob/80da=
28bc87aa0fb3ed600db9ba6cb2b8e18f5500/source/xep/omemo/LurchAdapter.cpp#L448=
</a></div><div>[3] <a href=3D"https://xmpp.org/extensions/xep-0384.html">ht=
tps://xmpp.org/extensions/xep-0384.html</a></div><div><br></div></div>

--0000000000000918aa05bca7799f--

--===============1103018386==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
JDev mailing list
Info: https://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [email protected]
_______________________________________________

--===============1103018386==--