[krbdev.mit.edu #9117] [Comment] profile write operation interactions with multiple files

[Greg Hudson via RT]

http://kerborg-prod-app-1.mit.edu/rt/Ticket/Display.html?id=9117
This is a comment.  It is not sent to the Requestor(s):

Some thoughts about the potential solutions here:

* The null solution is to document that profile write operations can only
affect the first file.  This essentially leaves the FreeRDP use case broken
for some (probably rare) configurations, as there would be no way to guarantee
that the realm KDC values from the default profile are cleared and replaced.

* We could make profile_clear_relation() work using the final flag, and leave
the other modification operations broken for multiple files.  This is closer
to a comprehensive fix than it first seems, as pretty much any FreeRDP-like
use case is likely to start with profile_clear_relation() to clear out any
values of affected relations from the default profile.  The final flag
currently only applies to sections, but we could make it apply to relations as
well.  The relation and its containing sections may not appear in the first
file, so profile_clear_relation() would have to develop additional logic to
add a dummy relation and mark it deleted/final if there are values in
subsequent files.  Although this solution requires a lot of special-case logic
within profile_clear_relation(), it requires far fewer changes than any of the
following ones.

* We could augment the tree data model to support the kind of overrides
necessary to make all of the write operations work within the first file while
semantically affecting the values across all files.  For instance,
profile_rename_section() might need to place tags in the source and
destination nodes of the first file's tree, indicating that subsequent files'
trees should contain no values at the source and the source section's values
at the destination.  The number of edge cases for this solution is pretty
large, and the profile data model is already stretched pretty fine, but this
option provides the cleanest semantics without changing any caller-visible
aspects of the profile model.

* We could create an operation to flatten a multi-file profile into a single
tree, rendering all of the write operations effective on data originating from
any of the files.  This operation could be explicit, or could be implicit on
rw_setup() or profile_copy().  Making it explicit requires attention from
callers, who might not realize it is necessary to handle rare configurations. 
Making it implicit on rw_setup() calls into question the implicit flush that
happens in profile_release(), as the flattened profile would potentially have
different contents than the original backing file.  Flattened profiles would
also need to be marked NO_RELOAD, which might be problematic if flattening is
implicit on profile_copy().