Re: Reminder and Agenda for Confidential Storage Spec Call - Feb 25 2021
Thanks Manu for the thoughtful reply.
Yes, this is a next step. Ideally, we'd map every feature in the spec today to
Once you document it (not just the list of requirements we've been going over
Sure, I'm happy to make a first pass on this. Any thoughts on the best format / structure?
Zooming out a bit to look at the big picture... thinking about how SQL was
Totally agree, standardizing SQL is a perfect example.
To replay your point back to you, but in a different context:
To clarify, I'm not arguing we don't need a standard. To work with the same analogy -- if we're building an SQL standard we should be looking very closely at MariaDB (and other prior art / SQL-like implementations) when developing that standard.
The process of standards are not to innovate (at least, not primarily). It's
Yes, I agree with that.
I guess one of my concerns relates to feeling like we're looking closely enough at what's out there, but as noted above I'm happy to make a start on that with CouchDB. Michael has mentioned some other prior-art (in the replication context) that could be reviewed here. I'm sure there's more and across other contexts? Is there other work to document all the prior art that I have missed?
The point of meeting 80% of use cases is important, but there's some subtlety in that. Is it 80% of the "total use cases" or 80% of the "most important use cases" -- those are two very different things. And are we dropping use cases because they're "too hard with the current spec implementation" or because "they're not that important"?
Regardless, the ability to have a framework of modularising or extending the capabilities seems like something we should seriously consider. That will minimise the risk of developers ignoring the spec because they're locked in to only working with what's provided out of the box.
> I understand CouchDB is not a specification, but as an implementation it's
Totally agree :)