Re: Mutation events replacement

On 7/7/2011 6:38 PM, Jonas Sicking wrote:
> On Thu, Jul 7, 2011 at 5:23 PM, Rafael Weinstein<rafaelw@google.com>  wrote:
>>> So yes, my proposal only solves the usecase outside mutation handlers.
>>> However this is arguably better than never solving the use case as in
>>> your proposal. I'm sure people will end up writing buggy code, but
>>> ideally this will be found and fixed fairly easily as the behavior is
>>> consistent. We are at least giving people the tools needed to
>>> implement the synchronous behavior.
>> Ok. Thanks for clarifying. It's helpful to understand this.
>>
>> I'm glad there's mostly common ground on the larger issue. The point
>> of contention is clearly whether accommodating some form of sync
>> mutation actions is a goal or non-goal.
> Yup, that seems to be the case.
>
> I think the main reason I'm arguing for allowing synchronous callbacks
> is that I'm concerned that without them people are going to stick to
> mutation events. If I was designing this feature from scratch, I'd be
> much happier to use some sort of async callback. However given that we
> need something that people can migrate to, and we don't really know
> what they're using mutation events for, I'm more conservative.
>
> / Jonas
Hmm... you don't believe the use cases and info on how mutation events 
are being used that Dave and I have posted and you don't have any 
alternatives.  Perhaps the conservative solution is do nothing.

You might ask Prof. Jan Vitek if his infrastructure can give you any 
information on mutation event uses.  He may also other ways to get such 
answers.

jjb

jjb

Received on Friday, 8 July 2011 03:49:02 UTC