On Wed, Oct 17, 2018 at 10:33:50PM -0500, Chris Muller wrote:
> > what David failed to mention is that in the last Board meeting, we encouraged him to put this into the trunk now, early in the release cycle. He asked for feedback multiple times before, and is asking for feedback again now, out of sheer politeness.
> >
> > So please, try this. It is a much cleaner and simpler implementation, which makes it faster, too. We want it. IMHO this should go in unless a *valid* objection is raised, meaning you should at least try it.
> 
> +1
> 
> Please appreciate the economy of looking at something that only
> provides a nominal improvement.  I hope you did not see my temporary
> objection as a true objection as much as a request to ensure there is
> some community consensus.  With what you've just reported, it sounds
> like we do, or at least its forming.  But we need to give users a bit
> more coddling than that meager web page to help them understand what
> they would need to do to change to a subsystem that is this critical.
> The mention of the serializers is what I'm talking about, but what
> data conversions are needed?  What algorithm conversions for apps?
> 
> One of the worst kinds of bug is one which calculates invalid data for
> a particular application (due new assumptions), but doesn't actually
> blow up, only to be discovered a long time later after potentially
> pervasive damage.  Dave, could you see any potential for
> different-calculations in yours to allow this sort of bug to creep
> into an existing application?

Yes there is potential for that kind of error, including the case of
an application that unknowingly relies on bad behavior and later fails
when the bad behavior is removed. This could be a real problem for database
applications, but it is hard for me to assess how big the risk is.

The unit tests will give you a fairly good idea of things that might
be issues. There are 7 failures and one unexpected pass when running
the existing Chronology tests.

With regard to serialization, it is handled as follows:

   Name: Chronology-Core-dtl.26
   Author: dtl
   Time: 8 December 2016, 8:23:28.539757 pm
   UUID: 9572cf6e-6c65-4205-9435-f82b6c169a98
   Ancestors: Chronology-Core-dtl.25
   
   Fix readDataFrom:size: and implement storeDataOn:
   
   Strategy - Always store instances of DateAndTime as if they were the old
   format with seconds, offset, jdn, nanos. This ensures that serialized
   instances such as those in the snapshot.bin of a Monticello archive can
   be read by any image.

Implementation is in DateAndTime>>readDataFrom:size: and DateAndTime>>storeDataOn:
and I expect that both Fuel and Ma-Serializer will need similar handling.

Dave