On 7/7/2011 6:38 PM, Jonas Sicking wrote:
On Thu, Jul 7, 2011 at 5:23 PM, Rafael Weinstein<rafa...@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
