Uploaded image for project: 'Fluid Infusion'
  1. Fluid Infusion
  2. FLUID-5836

Rethink the use of "source" type options distributions

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: IoC System
    • Labels:
      None

      Description

      Originally, options distributions of "source" type were the principal (and for a while, even the only) form that was used. Especially aggressive was the use of "removeSource" as an annotation to indicate that the options material distributed should not be resolved at the source site at all, but be "uprooted" in order to resolve at the target. In the light of recent improvements in distribution namespace handling and more finegrained priority resolution (ending in FLUID-5824), as well as a recent tour of the fragility of the "source" system (suffered in FLUID-5835), we should reconsider our widespread use of "source" types in favour of "record" types.

      The pending major update of the GPII universal architecture in https://github.com/GPII/universal/pull/425 for GPII-1318 features a much more aggressive use of "global options distributions". Rather than constantly reaggregating options into locally-named caches, the idea is that the ultimate target site of the distributions is targetted via a global selector. Priority amongst these distributions are then arbitrated by schemes such as FLUID-5824 and FLUID-5621. This allows us to have "global oversight" of a design and easily (especially with the aid of perpetually forthcoming tools) be able to determine all the sites which influence a particular target. The alternative is to create a chaos of "locally forward caches of junk" of which the FLUID-5835 failure is a prime example. Numerous sites try to advise the message bundle of a prefs editor panel, and the result is a mishmash of inconsistently named aliases for the same options (messageResolver, msgResolver, etc. in several different components). The resulting mess is almost impossible to understand and debug.

      In addition, the "source" scheme as toured in FLUID-5835 shows that it is liable to many other causes of failure than the particular regression we encountered. The user's expectation is that, when writing

      source: "{that}.options.thing" 

      that the target will receive EXACTLY the options that would have arisen at the source's option "thing". In fact, there are numerous reasons that this may be difficult to achieve. "thing" may itself be derived from numerous options source (blocks) which must all be seen at the point of the distribution, and whose priorities must be exactly preserved at the target.

      The "block filtering" scheme arose because of our requirement for "removeSource", which in turn was primarily motivated by our "third epicyclic version" for fixing the Uploader's design in advance of our current now almost completely hermetic dynamic grade resolution algorithm. That previous epicycle involved a rather baroque "complete options distribution" where we broadcasted a source of "

      {that}

      .options" to a target "real impl" subcomponent with "removeSource: true" and a bunch of exclusions in order to prevent infinite self-inclusion. This requirement, as well as the current rather inflexible workflow for options merging, requires that options distributions work the way they currently do - that is, the result of a source distribution is that "filtered blocks" from the source are added to the target's blocks, rather than the target being able to directly depend on the source's finally resolved options value (which would allow completely consistency to be guaranteed).

      As we start planning for the upcoming framework rewrite under FLUID-4982, we should also consider rethinking this widespread (especially in the prefs framework) use of "source" distributions. If we carry on with them, we should consider at least -
      i) eliminating the "removeSource" annotation, which should discourage some of the most confusing cases of "wholesale options forwarding"
      ii) reimplement the scheme to allow the actually resolved option to be forward rather than the raw materials for it, which should be much easier to achieve in the new "promise-like" world
      iii) generally recommend that "record" distributions plus globally resolved selectors be used instead, rather than the "facade"-type pattern we have been continuing to have in our minds under the influence of ancient-type thought received for example from GoF

      The "get it right first time" model of resolution has been an abstract goal of the framework for a long while. As our construction process becomes steadily more powerful, use cases which required objects to be constructed initially in only a partially viable condition, or else for options to be constantly cascaded through the system in many steps on their way to their ultimate destination can gradually be subsumed in the framework's workflow in general. The opportunity to get rid of further, specific, framework features (e.g. "removeSource") in favour of general capabilities of the instantiation workflow should be seized if we can.

        Attachments

          Activity

            People

            Assignee:
            antranig Antranig Basman
            Reporter:
            antranig Antranig Basman
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated: