[reviewing]

Sangwhan: IndexedDB has this thing called put - people have been asking for "put many things" - so you have to have a for loop, which blocks. If you have a huge amount of stuff you want to put in and then get an event at the end there is no solution for that. This is one of many things like this. Because of legacy reasons they don't want to move away from an event based architecture (vs async). So I brought that up. The original IDB editor commented. There was an attempt to try that but it didn't succeed.

Dan: so more to do ... on our side.

Sangwhan: some archaeology. The naming issue isn't so much of an issue.

Dan: sounds like a reasonable request...

Sangwhan: yes, it doesn't seem nice [the way it is].

[bump

[punt to plenary

Ken: I know a lot of people really want this for performance.

Sangwhan: I don't think this partial thing is really a big deal..

... if you do a partial you're breaking transactional guarantees. If you can't do further writes you've left your database in a broken state. Have to go through the remaining... seems weird. Should be all or nothing.

Alice: Basically in agreement with dmurph's comment..

Sangwhan: Yes.

Ken: I'm going to ask around about this, I don't know much about databases but I have friends who do, would like their input.

Sangwhan: I have some feedback...

... comment is that .. future considerations include an addAll API... similar to putAll but (??) entries in the same transaction.

... Would give feedback that that should come pretty soon rather than at some unclear future time. putAll proposal.. A=1 B=2 C=3 and A=4 in the same transaction... you're batching up a bunch of data and clobbering data in the same transaction... some cases where you want to be able to put those... some sort of programming error in a lot of cases. Would be useful to have this sooner rather than later.

... Discussion about returning to (?)... should be all or nothing.

... Happy to propose closing and discuss in plenary.

Tess: Good conversation on the issue but we don't really know if Dan or Ken have further issues that what's there. We shouldn't sign off without the assignees being here.

Peter: Has anyone contacted libs devs who would build on top ot this?

Rossen: Don't know.

Tess: Motivation stated is customer feedback, thus, we could assume they are interested.

Peter: That's reasonable.

Rossen: Push to Breakout C?

Peter/Tess: Yes.