Re: [Standards] Council Meeting Minutes April 5th 2017
On Wed, Apr 12, 2017 at 6:43 AM, Daniel Gultsch wrote: > 4) Vote on advancing XEP-0334: Message Processing Hints > Everyone to vote on list. -1 I've thought about this some more, and I still don't think it makes sense to have a "hints" XEP. In my opinion we should move towards obsoleting this XEP. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Meeting Minutes April 5th 2017
> On 12. Apr 2017, at 13:43, Daniel Gultsch wrote: > > 4) Vote on advancing XEP-0334: Message Processing Hints > Everyone to vote on list. > Sam considers voting -1 because it includes functionality that should > probably exist as part of other XEPs. > Daniel agrees that every XEP should define its own hints. > Requires more mailing list discussion. +1, ideally XEP-0334 would refer to the known XEPs that currently make use of the hint, as should the other XEPs the other way around. This isn’t an ideal solution but would be fine with me as it helps visibility on what hints exist and in what way they are used. Having an own XEP for each hint feels a bit over the top. Moving each hint to the XEP that uses it would lead to duplication of hints or one XEP using a hint defined in an otherwise unrelated XEP. Ultimately I do not care that much, only that we get to a solution and do not discuss this for much longer. Cheers, Tobi___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Council Meeting Minutes April 5th 2017
Hi, 2017-04-12 13:43 GMT+02:00 Daniel Gultsch : > 4) Vote on advancing XEP-0334: Message Processing Hints > Everyone to vote on list. > Sam considers voting -1 because it includes functionality that should > probably exist as part of other XEPs. > Daniel agrees that every XEP should define its own hints. > Requires more mailing list discussion. > I'm starting to lean towards -1 on this one. The main argument in favor of XEP-0334 seems to be avoiding duplication however I'm having a hard time coming up with legit use cases that reuse any of the hints. (no-)store is used by two different XEPs but one of those needs to be depreciated anyway. The no-copy hints are also only used by one XEP; and even if we replace Carbons with something else that might need a no-copy hint we should probably deprecate Carbons at that point. On the other hand defining the hints in their respective XEPs allows for a more precise definition of how one particular hint should behave in the context of that XEP. (Instead of having vague rules in XEP-0334 that try to be agnostic in regards to their respective XEPs.) >From an implementation point of view XEP-0334 also doesn't actually avoid any duplication. It's not like servers will suddenly have a 'XEP-0334 engine' that does all the processing in a single point. I'm guessing the processing will still happen in the carbons module and the MAM module or wherever. The only actually good reason to keep Message Processing hints is status quo and the fact that we probably need to bump the namespace of MAM again. But I don't think it's my job as a council member to make decisions based on status quo. I'm willing to vote 0 on that if someone (maybe from outside the council) can provide a good reason to keep XEP-0334. cheers Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
