I think we can all agree - at least that's my impression after reading this thread and some discussion on this in the channel - that both 0 and 2^31-1 are bad values. The only other numeric solution seems to be '-1' which doesn’t feel right to me.
All in all I’m in favor of keeping it as 'max' (this is also compatible with what's currently specced out; just in case someone we don’t know about did implement it. Whether or not the current PR is the 'correct' place to define this I don’t know. It's not an 'incorrect' place. However maybe we can also define this in 0122 instead? This would allow other XEPs to reuse this as well. I think this could be interesting for MUC (max number of participants) or some ad hoc commands scenarios as well. I'm probably going to vote +1 on this during today's council meeting. But I'm OK with being overruled by someone who prefers to stick it into 0122. cheers Daniel Am Mi., 16. Sept. 2020 um 22:51 Uhr schrieb Maxime Buquet <p...@bouah.net>: > > Hi Standards, > > > A year ago during a sprint we worked on implementing bookmarks2 and > submitted a few changes to the spec at the same time. > > We also submitted a change to PubSub [0] [1] to allow a client to say > “Set pubsub#max_items to whatever the server max is” so that multiple > clients don't rewrite each other's max value every single time > (alternatively saving the "get" step when configuring the node). > > This change to PubSub has been met with some ““resistance”” by the > prosody team because the proposed value “max” is not a number and > doesn't fit the way they currently handle things with XEP-0122 (Data > Forms Validation), setting this value to “integer”. > > While this is more restrictive than what PubSub mandates (text-single), > it does indeed make sense to have a “maximum number of items” be > restricted to an int (not discussing which particular type of int, if > there is). And while it's certainly not impossible for them to handle > this “max” value, that would mean going through various hoops with 0122 > to get this right. > > “-1” was proposed as a placeholder instead. > > While it doesn't exactly sit right with me wrt. semantics, I don't > particularly mind and I am currently looking for the path of least > resistance. > > So I just opened a PR. https://github.com/xsf/xeps/pull/984 > > Now I'm not entirely sure which path is gonna resist me most.. Prosody > or Council? :x > > I'm indeed introducing breaking changes for a one-year old feature with > this. I have to admit I'm not entirely fond of introducing yet another > disco feature for the exact same meaning and for a feature that's > probably not used[2], but I would update the PR with some guidance if > necessary. > > > Happy Hacking, > > > [0]: https://mail.jabber.org/pipermail/standards/2019-October/036502.html > [1]: https://github.com/xsf/xeps/pull/840 > [2]: Some clients implemented bookmarks2 during the sprint, but most > have put it behind a flag and/or not even merged yet. I don't think > any publicly available server implements it? > > -- > Maxime “pep” Buquet > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
