| Age | Commit message (Collapse) | Author |
|---|
|
This is the first convenience function implemented inside the xmpp
module but for the goroutine of the using application.
|
|
Some parts of the `xmpp` module functionality should be written for the
using application software. To reference a running session more easily
it is an advantage to have an opaque struct for this instead of
decoupled channels.
|
|
This updates from gioui.org v0.1.0 to v0.3.0.
|
|
|
|
|
|
Getting the roster (contact list) is crucial to provide a MVP LimoX
since the chats should be grouped by contacts.
For the MVP it is only relevant to get the roster on connect. Everything
else can be done later.
|
|
|
|
This completes the roster get / result cycle which is needed for a MVP.
|
|
This asks the server for the roster / contact list for the current
account.
|
|
It is quite tricky to write structs with correct XML struct tags which
are suitable for RX and TX because in RX structs all possible fields
have to be addressed and in TX some have to be hidden depending on the
use case.
|
|
This makes the code way less complex.
|
|
|
|
This will cover all iq use cases with optional arguments and
sub-elements.
|
|
The bind request / response works with IQ stanzas. Because of the way
encoding and decoding is done with LimoX / the Go standard library it
makes sense to group IQ-based logic in a separat file since the struct
for IQs will be there.
|
|
This adds the XMPP functionality to send and receive XMPP text messages
in one-to-one chats.
|
|
|
|
This demonstrates the full one-to-one chat message backend without the
need to implement the GUI.
|
|
This sets a handler and the routing up to be able to log chat messages
with body and sender reference.
This can later be used for the GUI.
|
|
This moves away from the concept to parse each individual XML token from
the token and group them as a []xml.Token slice for further processing.
While this is still possible, receiving aswell as sending has switched
to define structs with XML tags which can be marshalled and unmarshalled
with the xml.Encoder.EncodeElement() and xml.Decoder.DecodeElement()
functions.
Further documentation can be found at https://pkg.go.dev/encoding/xml#Unmarshal
and https://pkg.go.dev/encoding/xml#Marshal.
This merge reduces with its changes the number of code lines in the XMPP
implementation by around 41 percent!
|
|
|
|
|
|
This was removed for refactoring.
|
|
This prevents collisions.
|
|
Was broken because of switch to new RX concept.
|
|
|
|
This helps to avoid duplicated code when new XML elements are described
as custom structs.
|
|
|
|
|
|
|
|
|
|
This uses xml.Decoder.DecodeElement() which makes parsing way easier.
This first step is just able to parse stream features partially.
|
|
The new router will be so trivial that it is not worth a unit test.
|
|
This is more suitable for the new RX concept.
|
|
This was empty and has no benefit.
|
|
This will not be used in the new RX concept.
|
|
The new RX concept will not need such an element buffer and uses the
xml.Decoder.DecodeElement() function instead.
|
|
This was not really necessary because it was all related to the
xmpp.session and should thus be implemented there.
Using the context package further reduced the complexity for
cancelation.
|
|
The encoderDecoder sub-struct of the session struct should be removed in
little steps. This is the first one.
|
|
This is way shorter and serves the same purpose: It reflects the
responsibility of encoding and decoding XML. The encoderDecoder struct
should be removed soon.
|
|
The fact that it is actually about a pair of XML streams is obvious and
not that relevant. A shorter name has a higher priority.
|
|
This required the trick of defining an empty struct as `presence` type
but works pretty well. For sending data EncodeElement instead of token
handling should always work. Since it is simpler it should be used.
|
|
|
|
|
|
Gio started to use releases. LimoX should take advantage of this.
|
|
This fixes a race condition which was discovered during testing with a
bad network connection. Good network connections seem to hide this
error.
|
|
This removes the injected broken code which made the race condition
reproducible.
|
|
To make message passing to the XMPP session channel non-blocking short
living Goroutines are used. Before this commit they were executing
closures which capture l as xengineering.eu/limox.Limox pointer and used
it to get the channel where the message should be passed to.
While channels are safe with respect to race conditions, structs are
not. Thus the member access of the Limox struct was a race condition in
certain side cases like bad network connection where those Goroutines
lived for a longer time.
The solution is to make a copy of the l.sessionIn channel and use this
copy in the closures. This is valid since channels do not need pointers
to them and furthermore are thread safe.
|
|
This should make the race appear reliable if a second connection attempt
is made. It is important to have a reliable error to fix it reliably.
|
|
Logging used to re-encode tokens for receive logging and double-encode
tokens for send logging. This had the flexibility to pretty-print the
XML. Furthermore it was trivial to prepend a prefix like `S: ` and `C: `
for server and client.
This merge moves away from logging based on re-encoding XML tokens.
Instead the received or sent bytes are multiplexed to a logger which
uses the log module of the standard library to log the XML code.
These advantages come with this merge:
- [TX] / [RX] instead of C: / S: as prefixes (direction instead of node)
- encoding issues can be debugged via the log
- everything is now logged via the log module and has timestamps
The only disadvantage is that the logged XML is not pretty-printed
anymore. This is choosen for the RX stream to not accidentally hide
encoding issues and show what is really on the wire. That argument is
true for TX aswell and consistency is appreciated anyway.
|
|
LimoX does not care about these XML tokens at least for now. The issued
error messages on other levels.
Dropping those tokens on the encoderDecoder level asserts that the rest
of the xmpp code has only `clean` XML content to process.
|
