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.

/K

Reply via email to