To support reliable message delivery as defined in XEP-0198, the application needs to:

(1) count and acknowledge stanzas;

(2) buffer unacknowledged stanzas for redelivery in case of stream resumption;

(3) resend delayed stanzas in case of stream not being resumed.

Note that some clients that claim support for XEP-0198 implement `urn:xmpp:sm:3` (Psi+, Conversations, Gajim with python-nbxmpp>=0.5.6), while others implement `urn:xmpp:sm:2` (Swift, Gajim with python-nbxmpp<0.5.6). The revisions differ in how they count stanzas. Ejabberd supports them both simultaneously.

The level of support also varies. An application may:

(1) just count and acknowledge stanzas;

(2) resend stanzas on stream resumption;

(3) resend stanzas on reconnect without stream resumption;

(4) resend stanzas after the application is restared.

Psi+ supports 1 and 2, does not support 4, and probably does not support 3. Swift supports only 1. [2]

[1] It is also technically possible for the client to use XEP-0313 ("Message Archive Management") to retrieve undelivered messages and to discover and resend unsent messages, but the latter is not described in the XEP, and I'm not aware of the clients that do so. I have found this suggested by Holger Weiß at https://github.com/redsolution/xabber-android/issues/128#iss... , together with a clever (currently abandoned) extension of XEP-0313 with `urn:xmpp:mam:sub` that subsumes XEP-0280 ("Message Carbons").

[2] To study interactions between Jabber clients and servers, I wrote https://github.com/orivej/xmpp-logging-proxy that serves as a Jabber server by relaying communications to the actual Jabber server while saving the decrypted streams to files.

https://hub.docker.com/r/ortuman/jackal/tags/

  mike@ung:~$ sudo docker image ls|grep golang
  golang              1.10                6b369f7eed80        3 days ago          794MB
  mike@ung:~$ 

Should probably base it off an Alpine image instead. Would make it many times smaller.

[edit] In fact, there is a "golang:1.10-alpine" Docker image:

  mike@ung:~$ sudo docker image ls|grep alpine
  golang              1.10-alpine         05fe62871090        4 days ago          376MB
  mike@ung:~$ 

  FROM scratch   
  ADD main /  
  CMD ["/main"]

https://github.com/jaegertracing/jaeger/blob/master/cmd/quer...

[ed: well maybe not for a simple go project, as go has great cross compilation support. But if there's a bit of Javascript/(s)css/static resource munging - a container with a predictable build environment might become appealing. ]

I do that on CI as well, since building dependencies often takes longer than just downloading a full VM.

About other languages that are weakly typed in "current use":

- JavaScript is still weakly typed as far as I am concerned, nothing prevents you from 0 == "" and get true value. - PHP is still weakly typed, with optional type hinting but still sometimes can bite you in the ass

Erlang + Dialyser can be read as quasi-static typing, but it is still strong one.

[1]: https://www.igniterealtime.org/projects/openfire/index.jsp

We have two uses. 1. Web based per-page chat for all our logged in users, then using Candy+ejabberd/openfire, but now using a custom node socket based chat server. 2. Internal chat still on Openfire. Have thought of checking out Zulip/Mattermost et al.

Never tried Prosody, and feel that xmpp never got the client thing quite right.

  func (ctx *Context) SetObject(object interface{}, key string) { … }
  func (ctx *Context) Object(key string) interface{} { … }

  type rowScanner interface {
  	Scan(...interface{}) error
  }