Hi, 2017-04-12 13:43 GMT+02:00 Daniel Gultsch <dan...@gultsch.de>:
> 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 _______________________________________________