On 10/25/17 23:57, Jacob Carlborg wrote:
On 2017-10-26 00:53, Adam Wilson wrote:
This of course makes the assumption that we clean-room our own
protocol implementations which I am entirely against. Better to use
what already exists.
I'm entirely against anything that is not compatible with vibe.d ;)
My apologies, something rather the other direction. Instead of forcing
compat with vibe.d, going to vibe.d and say: "here is our standard
event-loop, it has everything you need, you'll need to use it for all
the other goodness to work". I know others can make good arguments about
why the vibe event-loop is insufficient, and I'll let them make them.
(Something about not supporting GUI loops, paging Mr. Cattermole). If
that is really the case I don't see how being entirely vibe.d compatible
and meeting the universal standard requirements of Phobos is possible.
There would need to be a requirements gathering phase so that the
community as a whole can bring their use-cases before we dove into code.
I actually don't think the slow updates are huge problem as these DB
interface libraries are pretty slow to change themselves. For example,
ADO.NET didn't change significantly from it's 1.0 release until the
arrival of Async/Await in .NET 4.5, which was 10 years later. The
biggest addition prior to Async was TVP support and that was tiny
comparatively and came in 2005.
The libpq5 interface has barely changed in years. I can't speak to
MySQL but IIRC it hasn't changed much either, at least not in a way
that would effect the abstraction layer.
I'm more concerned that I don't think we'll manage to implement a
complete API and 100% bug free at the first try.
Depends on how one defines first try. Phobos as a pretty solid process
for making sure these things are reasonably bug free. And near as I can
tell, Phobos is pretty good about accepting bug fixes.
--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;
