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

Assess the potential for modularising Infusion into one or more modules, and appropriate distribution scheme



    • Improvement
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 1.5
    • None
    • Build Scripts
    • None


      Our infusion image, stored in github at https://github.com/fluid-project/infusion , mixes together (at least) 3 different kinds of material, which are suitable for different audiences -

      i) cross-platform framework code (including the core framework, IoC, data binding, and parts of the preferences framework) which are suitable for all contexts, including the browser, node.js and possibly others
      ii) browser-dependent framework code (FluidView.js etc.)
      iii) browser-dependent components (e.g. InlineEdit, Reorderer)
      iv) definitions to assist testing (jqUnit. IoC testing framework)

      and for each of the above 4 categories there exist corresponding tests. Currently tests, together with definitions for iv) are consolidated across the above 4 areas in a top-level area named "tests".

      pull requests such as https://github.com/fluid-project/infusion/pull/544 have stalled since it is not really clear what we should do with our current npm image. We have made attempts to trim out browser-dependent code, but now that our node applications are starting to serve infusion to the browser, the issue has reopened - for development purposes, it would be helpful to serve broken-out versions of infusion from our own npm image.

      Our last concentrated thought on this issue dates from end June 2014, summarised on this wiki page: http://wiki.fluidproject.org/display/fluid/Notes+on+Modularisation+of+Infusion

      The following post on the npm blog suggests that the npm team are aware of this kind of issue and hoping to provision npm as an element of the packaging for all JavaScript projects - http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging - however, the post acknowledges that npm by itself is inadequate and requires some form of additional infastructure/build process. Our experience with "bower" also shows it to be inadequate by itself.

      For production client purposes we require a build step in order to build UIOptions' style sheets using "stylus". We also require a built image of the framework for these purposes.

      It's still not clear how to integrate build steps into the process of acquiring and serving the framework. Ideally we would have a separate module just for this purpose - however, it's unclear where it would then check out the base image of the framework from in order to operate the build - would it check it out of git itself, based on its own revision?

      In any case, it is clear that the development and review process of working with multiple modules (whether git or npm) is extremely painful and cumbersome, requiring multiple coordinated commits for related versions. This would be eased (but only slightly) if we moved over to more industry-standard practices for issuing releases. Part of the goals of our new module loader - http://wiki.fluidproject.org/display/fluid/Notes+on+the+Infusion+Module+Loader - relate to making an easy development and commit process for this workflow. JIRA at http://issues.fluidproject.org/browse/FLUID-5521

      There was discussion on this subject in IRC this week starting at https://botbot.me/freenode/fluid-work/2014-12-03/?msg=26724667&page=1 - the initial question was the fate of fluid.css within our npm module (currently excluded) which was required for the strategy of serving our framework image from our npm dependency.


        Issue Links



              antranig Antranig Basman
              antranig Antranig Basman
              0 Vote for this issue
              2 Start watching this issue