[Standards] Call for Experience: XEP-0048: Bookmarks
jonas at wielicki.name
Thu Mar 8 08:02:38 UTC 2018
On Donnerstag, 8. März 2018 08:28:27 CET Daniel Gultsch wrote:
> 2018-03-08 8:22 GMT+01:00 Jonas Wielicki <jonas at wielicki.name>:
> > On Donnerstag, 8. März 2018 07:38:42 CET Daniel Gultsch wrote:
> >> It feels a bit sad that we aren't able to advance a XEP that is widely
> >> deployed (in a way) but I think it is just too late.
> > Can’t we revert to XEP-0049 (if no other XEP-0223 implementations show
> > up),
> > advance *that* to final and make a new thing properly based on XEP-0223,
> > with multi-item layout and fancy stuff? I would love if we could take
> > that opportunity to add roster-like groups to bookmarks.
> I don’t think XEP48 over 49 solves the requirements we have today as
> outlined in my previous mail.
That’s very true, even though it *does* reflect the reality. Deprecation
maybe? Wouldn’t be the first thing we deprecate without real replacement…
> Further advancing that would benefit nobody (I don‘t think we would
> see even more implementations and on the other hand it might confuse
> new comers and guide them towards something that is just not up the
> requirements we have today)
In any case, having the XEP strongly suggest a mechanism which is in fact not
deployed is also adding (frustrating, because you end up implementing
something only to learn that it doesn’t work; similar for XEP-0084 vs.
XEP-0153) confusion for newcomers.
I also think that that the 223 version of things may need more experimentation
than Draft state may be able to deliver (for example, the single vs. multi-
item issue). Not to mention that multi-item PEP may have even more deployment
restrictions than persistent, private PEP itself.
But sure, leaving this in Draft as-is would work. But it doesn’t alleviate the
> Advancing this only for the sake of advancing something is misguided.
That’s for sure.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards