Re: [lmi] Calculation summary: tidying up loose ends

[Greg Chicares]

[I'm going over old messages that I had marked as needing a
response. I'm nine days behind on some that didn't need
immediate attention.]

On 2006-11-8 2:38 UTC, Evgeniy Tarassov wrote:
> 
> Oh, now i understand that there is a bug in configurable_settings
> code. As i have mentioned above if one specifies --data_path, then it
> does not affect configurable_settings.xml and it is read from the
> current directory. but when the code writes the
> configurable_settings.xml, the parameters are already passed and a new
> file will be created in that that directory, and as a consequence it
> won't be picked up during the next launch.
> 
> Do you want me to fix this by saving the configurable_settings.xml
> real path and using it afterwards?

Just to bring the thread to closure, I believe you coded this on the
branch and I ported it to HEAD.

BTW, I believe the program always looks for 'configurable_settings.xml'
in /etc/opt/lmi/ first--and, if the file is there, doesn't look anywhere
else. This seems worth mentioning because users typically install all
files to
  /some/place/lmi-2006-09/ [for September]
  /some/place/lmi-2006-10/ [for October]
  ...
and until now they've been given a complete set of files every month,
including 'configurable_settings.xml' even if its contents didn't change.
That's tidy for msw users: everything's in one place, and uninstalling a
release is one shift-del keystroke in msw 'explorer'; and they don't want
to hear about the unfamiliar glories of /var/opt/lmi/ . However, it means
that user customizations now saved in
  /some/place/lmi-2006-11/configurable_settings.xml
won't be seen by the December release. "Where did my settings go?"

However, if we begin installing 'configurable_settings.xml' for them in
/etc/opt/lmi/ iff it doesn't already exist there, then their settings
persist automatically, because the the *nix path dominates. I haven't
tested that myself recently--on my msw machine I use only /etc/ for
this--but it looks like it should work fine.

To keep that working, there's some stuff we must do--not this moment,
but before releasing any later version with a nonidentical set of
elements in 'configurable_settings.xml'. We must teach the program to
recognize obsolete historical elements that were removed, and handle
them in the correct way (most often by ignoring them silently): grep
for 'detritus' to see how this is done elsewhere. And it must also
ignore elements that it finds but cannot recognize, issuing a nonfatal
warning in that case. These steps secure both forward and backward
compatibility.

Probably the 'detritus_map' technique should be pushed down into
public nonvirtuals in class 'streamable' that call pure nonpublic
virtuals (do_ignore_detritus() for example). Then all "streamable"
xml files automatically benefit from uncommonly strong compatibility
guarantees, and the only maintenance required is adding code to
handle any element when it's removed--the lowest conceivable cost.

And, as I think our 'do_write()' discussion elsewhere on this list
would suggest, the Ledger class probably shouldn't be "streamable"
in this exact sense, but some classes that aren't "streamable" today
probably should be.