On 29 September 2015 at 16:02, Florian Schmaus <[email protected]> wrote:
> On 17.09.2015 13:31, Christian Schudt wrote: > > Hi, > > > > > >> I get your point. But it feels wrong to define nearly identical > >> extension elements in two XEPs. The author of xep334, Matthew Wild, > >> already expressed his willingness to change xep334 so that it can be > >> re-used in xep280. Therefore I'm all for changing xep334, then issue a > >> last call for it, ideally advance it to draft, then issue another last > >> call for a xep280 version using xep334 elements, and finally advance it > >> to draft. > > > > Speaking of reusing: Why not just re-use XEP-0079 here? > > Good point. After reviewing AMP (xep79), it appears to be well designed > in a modular fashion. This would mean that server developers wouldn't > need to implement all of it, just the required parts to achieve what > xep334 does. Please correct me if I'm wrong. > > > http://xmpp.org/extensions/xep-0079.html#description-match-resource > > > > action="drop" value="other" should do the same as <no-copy/> or > <private/>. > > > > In general XEP-0334 seems to have overlapping parts with XEP-0079, e.g. > <no-store/> vs. > > action="drop" value="stored". > > > > Actually I am in favor for not having two XEPs with the same use cases. > > While I was first an advocate for using xep334 in xep280, it appears > that using xep79 provides a good alternative. > > I've heard multiple times, including from one of the authors of AMP, > that AMP was a mistake. Could somebody elaborate on that? What is wrong > with it? I knew it existed, but didn't discovered until now that it's > modular (see Example 4). Hence the usual flaw of large specifications, > that you potentially need to implement all of it just to get a certain > feature, doesn't apply. > Yes, just like XEP-0060. XEP-0334 is advisory, XEP-0079 is mandatory. But worse, XEP-0079 has all manner of combinations - every time an action is added, every value supported must be checked. XEP-0334 managed to accomplish every useful use-case from '79 with considerably less complexity. Dave.
