Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use exml library for parsing XML #40

Closed
goj opened this issue Aug 28, 2012 · 2 comments
Closed

use exml library for parsing XML #40

goj opened this issue Aug 28, 2012 · 2 comments
Labels

Comments

@goj
Copy link
Contributor

goj commented Aug 28, 2012

No description provided.

@ghost ghost assigned rpt and studzien Aug 30, 2012
rpt added a commit that referenced this issue Sep 3, 2012
@erszcz
Copy link
Member

erszcz commented Oct 10, 2012

The main rationale behind switching to exml is the proper support for XML Namespaces.

The current state of XML handling in ejabberd is that it doesn't store the NS (namespace) of every element, but in general assumes that the NS is jabber:client and stores it as pseudo-attribute xmlns only when it knows it's different, i.e. declared by that element itself as an attribute.

What it means in practice is that we deal just right with the following example of XMPP stream:

<stream:stream xmlns:stream="..." xmlns="...">
  <iq>
    <query xmlns="some_query_namespace">
  </iq>
...

but wouldn't be able to cope with equally legal in terms of the standard example:

<stream:stream xmlns:stream="..." xmlns="..." xmlns:q="some_query_namespace">
  <iq>
    <q:query>
  </iq>
...

Firstly, some XMPP client might prefer the latter formulation and current ejabberd just won't understand it.

Secondly, it might prove to be a source of network usage optimization to declare often used namespaces only once and then use just the short prefixes for specific elements.

@michalwski
Copy link
Contributor

Further work is done in #183

@goj goj unassigned rpt May 14, 2014
michalwski added a commit that referenced this issue Aug 7, 2015
The second release of mod_mam
NelsonVides added a commit that referenced this issue Jul 23, 2021
As reported on the hive by Raffaele

```
I found a bug or undesired behavior with the Inbox module. So when we fetch the Inbox, we can order it by date right? Every Inbox response has this "delay" element with a timestamp.

However, it looks like when we perform any of the follwing actions, it resets that timestamp to the current time:
- Archiving/unarchiving
- Muting/unmuting
- Marking as read/unread

So that means that if, for example, I mute a conversation, then it gets bumped to the top of my inbox which is a bit strange.
```

The fix simply removes setting the timestamp, which I shouldn't have done to begin with, but for the query to be valid I need to do some simple comma-separator fixing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants