On 12 Aug 2015, at 16:14, Ralph Meijer <[email protected]> wrote: > > On August 12, 2015 4:50:18 PM GMT+02:00, Kevin Smith <[email protected]> > wrote: >> On 12 Aug 2015, at 15:44, Ralph Meijer <[email protected]> wrote: >>> >>> On August 12, 2015 3:07:44 PM GMT+02:00, Kevin Smith >> <[email protected]> wrote: >>>> The thread is moving somewhat away from Carbons Last Calls, but this >> is >>>> all related so I won’t feel too guilty. I have two opinions here: >>>> [..] >>>> 2) Carbons will need some changes in the (hopefully near) future >> once >>>> the pubsub/account stuff is specced/we have deployment experience. I >>>> believe this means that going to Draft now wouldn’t be appropriate, >> as >>>> knowing there will be backwards-incompatible changes is at odds with >>>> the Draft requirement of avoiding such things where possible. >>> >>> * Does this mean you'd vote -1 if Carbons remains mostly as-is for >> now? >> >> For Draft, yes, which is very different to saying I think it has no >> merit, or that I don’t think an appropriate version should go to Draft. >> Voting something to Draft when I think it’s likely to need further >> changes seems inconsistent with xep1. >> >>> * How do you feel such backwards incompatible changes would work out >> in practice? I do feel implementors take a risk in putting experimental >> specs in production, but also see the high-profile nature of this work >> and the bigger context with other IM systems. >> >> I think they’d work out as a new namespace, but I’m not sure. If we >> could get the other pieces in place we’d be able to see the bigger >> picture and be more confident in these things. I think that MUC2 is not >> a prerequisite part of these other pieces for Carbons to be able to >> advance, but defining how it interacts with Pubsub/Account seems >> necessary. It also seems necessary to include type=normal (I think we >> can get away from type=groupchat, thankfully, cleanly in the >> MUC2/PubsubAccount approach). >> >>> * Could your envisioned changes be add-on instead? I.e. is there a >> chance of future proofing this (now)? >> >> Possibly, but I don’t think we’ve got the picture firm enough yet. > > So the question is, do we need to make this spec to be the perfect solution, > or is Carbons good enough for now?
I think it’s good enough for people to use now and get benefit. Indeed, I would suggest people go ahead and implement the current version - but that’s because I believe future changes shouldn’t be onerous, not because I don’t believe they’ll happen. Note that I’m not opposing any change to Carbons that’s been suggested (of which I’m aware), nor am I preventing publication. So while I can see that my position of this not being (quite) the right time to move to Draft is annoying some people, I don’t think this is preventing practical progress, and I believe it’s saving time later to avoid pushing to Draft prematurely. The point of Experimental is to get XEPs published and discussed and implemented and experimented with so that we can move to Draft when we believe they’re addressing the problem appropriately. I’m very keen on these things happening. > We've seen a lot of hinting at improvements, and I do remember your own > suggestions, but I wonder if we couldn't do that in a new spec instead. When > have we waited long enough to decide this is the best we can do for now? Well, that was the proposal I made earlier this year, and there was wide agreement that a new spec was the wrong approach, and waiting for Carbons was right. I’ve even convinced myself at this point that waiting for Carbons is probably right. Dave - do you have an ETA on the pubsub/Account stuff? I think that might help matters significantly. /K
