On 2016-10-06 8:43 AM, Matt S Trout wrote:
On Tue, Oct 04, 2016 at 08:17:49PM -0700, Darren Duncan wrote:
That would be good, also in light with how that sentence continues:
"I suspect what we need to try and achieve is to get DBIC a bit more
decentralised - have it be a specific framework build atop a
more-like-Plack-for-DB-stuff - but you already know that's what I
have in mind and we both already know it's going to be a big-ass job
and we'll see if it pans out or not."
My own near term planned contributions to DBIC are precisely what
you said above. They would constitute a more-like-Plack-for-DB
ecosystem and in particular they should benefit DBIC by optimizing
it more for maintainability, so it is easier for others to add
features or make changes or otherwise just be more confident that it
works properly. If things go as I hope, this should start to land
in about a month.
I think anything that's in that sort of vicinity is likely to be a big
enough set of changes that it'll (a) need to wait until whatever new
administration we end up with is settled in (b) need a decent RFC process
and advance discussion of the risk/reward trade-offs involved.
After all, when I say "big-ass job" I'm generally not kidding about that,
and at this point it looks like it's not only going to be a big-ass job,
but a big-ass job we're going to have to conduct without the help of the
person I was relying on being the other half of the architecture team for
it.
So, I mean, "cool" but also "this is going to need serious discussion" and
especially "please don't get your hopes up about 'near term'".
Not to worry, and I agree.
The first version of the thing that I was intending to land in the short term
was only intended to be, on its own, classified as a green field experiment or
proof of concept. It would NOT by any means be intended for production as is.
Basically I am working on a Plack-for-DB as an independent project, and I was
going to use an experimental fork of DBIC (on GitHub) as an initial test case by
roughly replacing DBIC guts to use that project while using the fact that DBIC's
pristine automated test suite as a validation that DBIC still behaves correctly
with the changed internals.
The new administration of DBIC can then use this working proof of concept in
their discussions on how they want to formally evolve DBIC. My experiment would
constitute an RFC for how would you like to use my Plack-for-DB, or adapt its
design, to implement DBIC features that were long desired but not provided.
-- Darren Duncan
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk
