JeybeTo check supported xeps on a specific server one needs to be logged in, correct?
flowJeybe, depends, simply querying the disco#info of the server's address may already reveal most XEPs
flowbut obviously not the ones that are only exposed to users of this service
JeybeTo mention, I'm completely new to XMPP development (and so the conrecte XMPP and XEP specs) and mostly new to development in general.
The XEPs I'd like to check are the ones from the Compliance Suite
flowJeybe, well you could simply get the source code of the compliance checker and look how the checker does it
Ge0rGJeybe: some relevant features like Push and MAM are probably only visible on your own account JID, not on the server JID
Ge0rGso yes, you need to have an account
JeybeMakes sense, as for the tester on compliance.conversations.im also needs account credentials
Ge0rGthe code behind is https://github.com/iNPUTmice/caas
flowthats why I am in favor of stuffing those features also in the disco#info response of the service's address: you don't need to have an account to check how widespread an xep/feature is implemented
pep.or maybe with this you mean I shouldn't shadow
pep.and prefer the left version
flowwhere is something shadowed in the left/right examples you showed?
pep.In the right example the child xmlns shadows root's
pep.the second child
pep.Which means if this child has descendants, I won't be able to reuse root's ns without redeclaring it
flowbut in xmpp we tend to not re-use jabber:client once an extension element namespace has been declared
flow<forwarded/> being one prominent exception
Link MauveAn exception would be forwarded or MIX.
flowahh MIX, really?
Link MauveMIX-PRESENCE IIRC.
flowcause its in pubsub potentially
flowanyway, I am not sure what you are asking, or if there is a generic answer to your question
Link MauvePresence in PubSub! \o/
<status>Making a Brew</status>
flowbut if your codebase is so far feature complete that you think about saving bytes… ;)
pep.flow, no I'm just curious, I have to make a choice :P
Link Mauvepep., what I’d do would be to let the user declare the prefixes they want on the root <stream:stream>, if XEP-0044 negociated it’s allowed, and only use prefixed elements if their namespace has been defined there.
pep.My implementation does left at the moment
pep.But our tests do right
flowpep: smack would (potentially) prefix presence in this case
flowwith the rule I mentioned before
pep.let me test on real data
pep.Link Mauve, minidom doesn't have the knowledge of "stream header" or not
Link Mauvepep., yeah, so it should be handled at another layer, which is why I said “let the user”.
pep.Sure, with the new API I let the user define custom prefixes