On 3/15/2010 11:01 AM, Jeremy Orlow wrote:
Specifically, what was asked from us by various web developers was the event based model for two reasons (as I recall): 1) The ability to have more than one callback per operation without rolling your own way to do this. 2) Web developers are very familiar with event based APIs already, so there is some mindshare gain.It'd be great if others (especially the proponents of the event based model) could weigh in on whether they like this and/or what changes they might make.
Now, I'll agree that (2) isn't a very strong reason, and I thought there were actually three reasons they gave us, buy my mind is a bit rusty.
With all that said, I implemented a callback-based API a year or two ago for Mozilla for our SQLite wrapper. It isn't hard to implement, and I'm not sure if we've had a need for more than one callback being registered. I'm only pushing for an event-based API really because that's the universal feedback we got from a variety of web developers. I'm not sure if any of them have had the opportunity to take a look at the current API however.
I feel that the event-based API is more powerful, but maybe only marginally so.If I were trying to write code on the bare API, personally I would prefer a callback based model, but perhaps I'm just odd. On the other hand, I think we've made it pretty clear that ease of use is a much lower priority compared to making an API with a small surface area that is powerful and is able to be wrapped by user friendly libraries.
To be honest, I haven't been looking at the sync API much at all. I figure the async API is more important first since not all UAs even implement workers at this time. With that said, I hope to look at it in the next few weeks.So, in summary, I've actually been arguing against what will make my life easiest. But maybe we should just leave the async API as is and move on?
Cheers, Shawn
smime.p7s
Description: S/MIME Cryptographic Signature
