jdev - 2022-01-28

Can somebody crash course getting disco info from accounts in roster? Caps are sent in the directed presence and it's up to the client to iq/get the resource if it wants to know? (also valid for my own other resources?)

Correct. Get caps in presence, check against caps cache, if missing disco client, check and shove result in cache.

ta

What about people not in the roster? I can disco their barejid but I'm not given a fulljid unless they specifically put it in @from?

@from on a directed presence? that'll always have their full jid there

@from on any type="available" presence you receive, actually

Do I get a directed presence from somebody not in my roster?

only if they explicitly send it to you

Do clients do that?

probably not

Ok

fulljids are also found in the @from of IQs and messages though

So if I don't get a directed presence I'm likely not getting their device capabilities

correct

s/likely/at all/

Ok

you'll also never notice when a device goes offline or when their capabilities change

if you got directed presence? then the server should send you unavailable when they go offline

Zash, "if I don't get a directed presence"

ah

well then you are in the dark

pep.: you can't disco bare jid if you're not in the roster (see my recent email on standard@ about that).

> s/likely/at all/ > I'm at all not getting :P

How do you usually go about parsing the xmpp stream? You can't just use regular DOM with it can you. Are you supposed to use SAX? But I never understood how people use SAX for anything but the simplest of documents, and from reading XEPs xmpp's structure seems to be far from simple. Any patterns/suggestions?

SAX, and it's not that tricky actually

so in aioxmpp, I structure the XML events directly into python objects representing the stanzas, according to the schema declared by the library and the application.

you *can* use a regular DOM parser, with some hax

but there's also a mode where stanzas are written into a DOM

if you have a DOM thing which you can feed with SAX events (lxml has that, for instance; but it can also very easily be built from scratch if you have a DOM manipulation library), then you can use the SAX events to create an individual DOM for each stanza

if you're into the pain of using DOM

regardless of parser the biggest thing to be aware of is needing to disable 90% of the things XML can do to just get to the subset XMPP uses

oh yes, ^

otherwise, happy billion laughs

depends what you are doing too, I guess a client can probably get by not worrying about it and trusting their server to sanitize for them but meh

I typically read with a stream parser, and then construct a pseudo-dom from it.

Pretty much how Prosody works too

Either way seems to take lots of code

Especially "directly from sax" approach, looking at aioxmpp source

the direct from sax magic is in aioxmpp/xso and aioxmpp/xml.py, everything else is then just schemas (which are really useful no matter which approach) and business logic

https://hg.prosody.im/trunk/file/tip/util/xml.lua this is a simple schema-less sax->dom approach

plus the DOM implementation in https://hg.prosody.im/trunk/file/tip/util/stanza.lua

wouldn't say that this is "a lot of code" :)

(considering the amount of business logic involved with xmpp in general)

https://hg.prosody.im/trunk/file/tip/util/xmppstream.lua is the one actually used for parsing xmpp

oh yeah, I meant to link that

has some session related logic in there tho

my history failed me

The extra stuff in xmppstream is mostly about stanza size accounting, and associating streams with XMPP sessions

The DOM-building part is the same as util.xml in the first link (at least, it is since a couple of weeks ago... :) )

and yes, it's quite straightforward and I've written equivalent code a bunch of times in a bunch of languages and environments

It's definitely my preferred way of doing things

goffi: right, thanks