On Fri, Nov 21, 2014 at 1:48 PM, Dan Wells <[email protected]> wrote: > Hello Liam, > > > > Thanks for the input. One thing I do want to clarify is that fine > generation even in case #1 would still be functionally independent of the > checkin code. (It has to be, since fine generation for most installations > is set to happen continually, or at least daily.) Plan #1 would simply > open up the possibility of doing the checkin/fine processes in a single > transaction. > > > > The main problem with plan #2 is not the generation component of fine > handling, but all of the other possible alterations and adjustments to > fines which can happen depending on the checkin conditions. I do agree > that #2 is better from a design perspective, but it is quite a bit more > complex than your outline suggests, and it would (in my opinion) be much > safer to approach that design iteratively, which is what I hope doing #1 > first would allow us to do. >
If pushing all of the fine creation/mangling into a single transaction (which would be ideal) is (part of) the main goal, then +1 to an iterative approach where we start with #1 and evolve to #2, since #1 is required regardless. +1 to streaming checkout as suggested by Mike, when we reach #2. Getting the initial response faster would be a nice bonus. -b
