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

Implement "new demands blocks" using simplified approach looking up grade names to grade names

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: 1.5
    • Component/s: IoC System
    • Labels:
      None

      Description

      As a result of our discovery, in http://issues.gpii.net/browse/GPII-209 , that demands blocks as implemented in Infusion must be removed from the implementation and framework, it was believed possible to cover all use cases for demands blocks using existing framework functionality.

      As a part of the work for http://issues.gpii.net/browse/GPII-75 , we are coming to implement socket.io capability for applications using Kettle, and it has surfaced that the above belief is incorrect, and that some use cases indeed remain for which old-style demands blocks are the only current possibility. These use cases centre around cases of genuine "multiple dispatch" - that is, implementations which should be selected only if multiple, orthogonal, conditions on the environment are met simultaneously.

      In this case the issue is revealed by provision of session support for socket.io enabled Kettle applications. A particular implementation grade, "kettle.use.session.io" was required only if BOTH the "kettle.server.io" grade were present, AND the grade "kettle.use.session". This was formerly implemented with a manual grade lookup with "if" statement, held in the file "session.js" which should properly have had no dependence on the io infrastructure - with an invoker bound to the following free function:

      kettle.server.io.getSessionIOGrade = function (gradeNames) {
      if (gradeNames.indexOf("kettle.server.io") >= 0)

      { return "kettle.use.session.io"; }

      };

      without the use of "old demands blocks" or some similar functionality, it would have been impossible to organise the dependence structure of these files properly.

      This problem, and many similar, could be resolved by a much simpler system than "old demands blocks" which makes use of two pieces of framework infrastructure developed since their implementation - i) dynamic grades implemented in FLUID-4916, and ii) "index defaults" given a basic implementation for FLUID-5067.

      In this new system, we only perform "multiple dispatch resolution" on the unit of entire grades, rather than individual invokers and listeners as implemented for FLUID-2881 demands blocks. This simplifies the system hugely, as well as improving its performance, since the resolution will only occur on instantiation and not on every dispatch at runtime.

      We propose a system which holds a lookup of lists of grades ("context names" in the old terminology) to lists of grades ("output grades"). Whenever a component is found whose grade content matches an element in the index, the output grades are added to its grade set automatically.

      In order to avoid the mistakes which prompted the the GPII-209 work in the first place, we propose that the index for this new system will be encoded by a standard fluid.defaults block - as a result of being given a unique name, this record will thus remain identifiable and can have a clear semantic in the case it is reloaded. "old demands blocks", not being associated with a particular name, were not identifiable and so could be given no clear reloading semantic.

      We propose a "draft implementation" for the time being to be trialed just in Kettle but to be elevated into the main framework once we are satisfied it is adequate. Initially we will have an "opt-in" system with a distinguished grade, say, "kettle.dynamicGradeLinkage" as a parent grade to be used by any grade wanting access to the dynamic resolution system.

      A user wanting to register a "linkage record" into the system would issue a defaults block like the following:

      fluid.defaults("kettle.sessionIoLinkage",

      { gradeNames: ["kettle.gradeLinkageRecord", "autoInit"], contextGrades: ["kettle.server.io", "kettle.use.session"], resultGrades: "kettle.use.session.io" }

      );

      This defaults record encodes the fact that any grade holding the content "kettle.server.io" and "kettle.use.session" (as well as the temporarily required "marker grade" "kettle.dynamicGradeLinkage") will automatically have the grade "kettle.use.session.io" appended into its grade content.

      The current implementation of fluid.indexDefaults has very inadequate performance but could easily be upgraded in time, without disturbing existing users of this API. The linkage implementation would then query for all defaults of type "kettle.gradeLinkageRecord" in order to look up the "resultGrades" on instantiation of components opting in with "kettle.dynamicGradeLinkage".

      An open implementation question is to allow matching on all context names up the component tree, as with "old demands blocks", or to keep the resolution self-contained with the current component. This promises getting into all the complexities required for FLUID-4917 "demands block horizons" but would tidy up the remaining contextual use cases as currently required for the Uploader component. Given this greatly simplified implementation strategy we could probably rethink the horizon system into something much simpler.

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: