-
flow
just to check if my memory serves me right: there is no way to query the xmpp server for pending in subscription requests after you have send the initial presence, right?
-
Ge0rG
flow: you could do a roster pull I suppose
-
flow
Ge0rG, I don't think so
-
flow
as I believe I will only found the pending out subscription requests in the roster✎ -
flow
as I believe I will only find the pending out subscription requests in the roster ✏
-
Ge0rG
I'm always struggling with corner cases of presence subscription management in multi-client situations, and each time I wonder whether it's a bug in my code, a bug in the other clients, a bug in the server or a bug in the spec
-
MattJ
Ge0rG, FWIW there are almost certainly bugs in Prosody regarding subscription stuff (edge cases that don't 100% match the spec, or potentially stuff not covered by the spec)
-
MattJ
But coming up with a test suite that covers everything is pretty hard, it's one of the things I wrote scansion for
-
Ge0rG
MattJ: my pet issues revolve around accepting / rejecting a request on device A and not seeing it on the simultaneously connected device B
-
Ge0rG
MattJ: not sure if you can scansion two parallel connections
-
MattJ
You can
-
MattJ
Most tests involve multiple connected clients
-
Ge0rG
MattJ: well then!
-
Ge0rG
Let me append that right to the end of your infinitely long TODO list.
-
MattJ
It's already on there, of course
-
MattJ
Being infinite
-
jonas’
nobody said that the entries are unique, also I’m pretty sure you can have an infinitely long TODO list with only unique items without all possible entries occuring
-
jonas’
for example, if your list consisted only of entries matching the regular expression a+
-
flow
To be fair, I don't think that this is an edge case and that it is actually not that bad that there is no method to query the server for pending in subscriptions, as it forces you to do the right thing™: setup a callback/listener/hook for pending in subscriptions, and after that, send the initial presence, handling the list of pending subscriptions client-side
-
goffi
Hi, I'm implementing "max_items" node configuration in my pubsub component, but I don't see any standardisation in XEP-0060 (it's just present in examples)
-
Daniel
goffi: it's registered
-
Daniel
I think
-
jonas’
for certain definitions of registered
-
Daniel
16.4.4 pubsub#node_config
-
Daniel
> for certain definitions of registered Yes
-
goffi
Daniel: I see it's there: https://xmpp.org/registrar/formtypes.html, but still, it's unclear
-
goffi
I have a few questions actually, mainly 2: 1) why using "max" which forces to use "text-single" for the field, instead of 0 or -1 for no max? Is there a legitimate reason to want a node with 0 for max items?
-
goffi
2) what do to when a config is changed and max_items become smaller than the actual number of items? Delete all extra ones? If so, there is a risk to delete accidentaly items (I think this happened to Movim with microblogging, because some buggy clients where changing max_items to 1)
-
Daniel
Pubsub is only a cache anyway
-
Daniel
So implementations just have to deal with vanishing items
-
MattJ
goffi, the 'max' thing has been discussed here a few times
-
goffi
what? No
-
goffi
it's definitely not "just a cache"
-
Daniel
You should read the xep again
-
MattJ
We (Prosody) are not happy with it, because we have form validation and there is no existing data type that matches "usually a positive integer, sometimes a string"
-
goffi
Daniel: I don't see where the XEP says that
-
goffi
MattJ: the type is quite bad indeed
-
goffi
Daniel: may be you should read the xep again :-/
-
pep.
Daniel: no it's not just a cache. Maybe that's true of omemo, not pubsub
-
pep.
(of the usage omemo does of pubsub, bot pubsub itself*)✎ -
MattJ
I certainly agree that pubsub is not just a cache
-
pep.
(of the usage omemo does of pubsub, not pubsub itself*) ✏
-
goffi
I'll have to follow the thing and use text-single, but that's a really unfortunate choice.
-
Daniel
Can someone point me to normative language on how persistent items and Max items is supposed to work?
-
goffi
there is no normative for "max_items", that my point, it's only present in examples (and examples are not normative as far as I know)
-
MattJ
Yeah, it's lacking
-
goffi
Actually, most of pubsub config is not normalized properly.
-
Daniel
The language I can find leads me to believe it is a fifo cache
-
MattJ
There is also inconsistency between ejabberd and Prosody I believe
-
Daniel
> Note: If the service or node is configured so that there is a maximum number of items cached at the node and the maximum is reached when an item is published, the service MUST delete one of the existing items. It is RECOMMENDED for the service to follow the "first in, first out" rule and delete the oldest item.
-
Daniel
So you don't get an error on publish
-
Daniel
It Transparently deletes the oldest
-
goffi
Daniel: that when max_items is set indeed, that the behaviour I would expect (I'm not happy with the "MAY" result in sending a delete notification though)
-
goffi
but my issue is when the config is changed, not on publication
-
goffi
I think I'll not change the max_items and return an error if there are more items than the requested max_items, user will have to delete/purge manually before changing the settings. That's better than deleting items by accident.
-
Daniel
Right. But what's the default value for max_items
-
Daniel
You say it's only a cache when max items is set
-
goffi
my server doesn't have max_items for now, so I'll set a default to "max".
-
Daniel
So how does it behave if it's not set
-
goffi
s/server/component/
-
Daniel
I can't find normative language in the xep that tells me that max_items is by default unset or 'max'
-
Daniel
Therefor I conclude it's a cache by default
-
Daniel
Even if your implementation isn't
-
goffi
There is no normative language for max_items at all
-
goffi
that's one of the main issue with pubsub, it's not normalised enough and implementation differs on this kind of important points.
-
Daniel
Note that I don't want it to be a cache
-
Daniel
But I think there is a reading of the xep that leads you to believe it is
-
goffi
Daniel: I think we agree on the behaviour of "max_items", but I disagree when you said previously "implementations just have to deal with vanishing items"
-
Daniel
Also I think that prosody for example does in fact have a limit
-
Daniel
Which if it them adheres to the rest of the xep makes it a cache
-
goffi
Daniel: I have implemented many features on top of pubsub (blog, tickets, merge requests, etc), and it's clearly not an option that items are randomly disappearing.
-
Daniel
Maybe a large cache of 1000 of whatever the limit is in prosody
-
Daniel
goffi: I agree. But don't blame the messanger
-
goffi
Daniel: the config has to be checked (either with publish-options or by getting the config) by the client anyway, max_items need to be set by the client IMHO, we can't rely on supposed default behaviour.
-
goffi
Daniel: I'm not blaming you ;)
-
Daniel
Yes the max items has to be set. Especially for pubsub on the account
-
Daniel
Where the default is 1
-
goffi
anyway thanks all for the feedbacks, I have my answers :)
-
pep.
Time to PR pubsub? :p
-
goffi
pep.: yep, I can do that but I don't know when
-
goffi
I have a bunch of work on XEPs accumating in my TODO list, I guess I'll have to block a couple of days for that.
-
pep.
goffi, I guess even just mentioning that in the wiki or something would be great already. We have a page for pubsub I guess?
-
pep.
(without looking for normative language right away)
-
pep.
https://wiki.xmpp.org/web/XEP-Remarks/XEP-0060:_PubSub
-
Daniel
The thing is that even when a client sets it to max, it's still a cache
-
Daniel
Because Max is not defined as unlimited but as what ever the server internally has as a limit
-
pep.
It's not a "cache" then, we just need to make it obvious on publish that there's not space or sth :/
-
Daniel
So you have to change the normative section I quoted earlier
-
MattJ
Yeah, I think there should be a way to specify the behaviour
-
pep.
yeah
-
pep.
I don't think I like the "When a new item gets published, delete whatever" part
-
MattJ
I don't want to change it - the current behaviour is often desired (though I agree "delete whatever" needs to be less vague)
-
Daniel
> It's not a "cache" then, we just need to make it obvious on publish that there's not space or sth :/ I agree that this is where we want to end up. But agreeing on that doesn't mean that it's already the case
-
MattJ
A related issue is when you publish an item with the same id as an existing item
-
pep.
I don't think deleting an item on publish is good for anything that goffi mentioned. blog, bug tracker, etc.
-
pep.
"Yo I published a comment and your article disappeared"
-
pep.
(might not happened because these two would probably be on different nodes, but fun nonetheless)
-
Daniel
Yes or bookmarks
-
pep.
yes
-
pep.
"I don't understand, whenever I'm joining a new groupchat, I'm leaving another" :p
-
Daniel
There is a discrepancy between what pubsub says and who we want to use it
-
Zash
Singleton node, FIFO of size n, fixed-size (conflict on publish if limit is reached)
-
Zash
I guess much of this comes from Pubsub being too generic to be usefuly without additional logic
-
goffi
MattJ: what is the issue with publishing on the same id as existing item? I belived the XEP explicitely says somewhere that it's then overwritting.
-
Zash
I thought that this was the same as removing that item and publishing a new one.
-
MattJ
goffi, I'm not aware of such text
-
MattJ
Ah, it does use the word "overwrite"
-
MattJ
It's in 7.1.3 Error Cases: https://xmpp.org/extensions/xep-0060.html#publisher-publish-error
-
goffi
MattJ: It's even in success case: https://xmpp.org/extensions/xep-0060.html#publisher-publish-success (the note under the example)