Re-unite UD-Viz with iTowns (or let it die?)

[EricBoix]

UD-Viz can be considered as a shallow-layer on top of iTowns that provides some prospective widgets, syntactic sugar, utilities, 3DTiles-extensions... Hopefully the UD-Viz code was originally thought as a sandbox for new, specialized or extended features of iTowns and UD-Viz code was to be contributed back to iTowns (and/or some portions of code would simply die out). Alas, and mainly because of early poorly conceived organizational ideas (e.g. all widgets should stand in a side-bar, css of widgets were defined inside the widgets as opposed to handled over to the constructor...), UD-Viz code drifted apart from iTowns and the code became bloated.

A recent internal effort was done in order to bring back UD-Viz closer to iTowns

• some UD-Viz code was contributed to iTowns (or at least iTowns was influenced by some minor aspects of UD-Viz) taking the form of a couple iTowns PR
• widget css is now defined outside of widgets
• code file hierarchy was seriously re-organized
• unused features were removed
• UD-Viz is now a mono-repository with lower level multiple (npm) packages
• ...

This was made possible by improvements of iTowns, e.g. the apparition of widgets within iTowns or the upcoming iTowns new (npm) packages breakdown.

This is an opporutunity for UD-Viz to be broken down in much smaller (npm) packages in order to

• facilitate contributions to iTowns
• avoid the ossification/code-bloat of UD-Viz (and keeping it alive, small and used)

In particular UD-Viz could be transformed to be an iTowns fork (a mono-repository holding a larger set of packages) in order to facilitate iTowns contributions with

• a package per widget each of which living on a different branch
• a package per data-model extension (e.g. 3DTiles extensions)
• a package gathering residual utilities

Additionally

• @ud-viz/node should be externalized to a separate repository (open question: how to deal with @ud-viz/shared shared dependency)
• all the widgets that depend on specific servers should be moved from UD-Viz to be hosted within the repositories holding the server code (refer to this SpatialMulmediaDB discussion).

Note: document

• what UD-Viz-template would become (iTowns-template ?) within this target package architecture
• what a new VCity application would look like (import @itowns/xxx and @udviz/yyy packages)

[valentinMachado]

Here a diagram to visualize changes wished

Current architecture

flowchart TD
  subgraph UD-Viz_github
    subgraph packages
      subgraph shared
      utils_shared
      game_shared
      end
      subgraph browser
      3DTilesExtensions
      ud-viz_widgets
      game_browser
      smdb
      utils_browser
      end
      subgraph node
      game_node
      utils_node
      end
    end
  end
  subgraph itownsFork_github
debug
    subgraph itowns_packages
      core
      itowns_widgets
    end
  end
  subgraph smdb_github
    smdb_backend_code
  end

core-->debug
core-->itowns_widgets
itowns_packages-->browser
  utils_shared-->browser
  utils_shared-->node
  game_shared--->game_browser
  game_shared-->game_node

Target architecture

flowchart TD
  subgraph UD-Viz_github
  end
  subgraph smdb_github
    subgraph smdb_package
      smdb
    end
    subgraph smdb_backend_code
    end
  end
  subgraph game_github
    subgraph game_packages
      game_shared
      game_browser
      game_node
    end
  end
  subgraph itownsFork_github
    subgraph itowns_packages
      core
      debug
      widgets
      3DTilesExtensions
    end
  end
  subgraph utils_github
    subgraph utils_packages
      utils_shared
      utils_browser
      utils_node
    end
  end

  UD-Viz_github-->|split|smdb_github
  UD-Viz_github-->|split|game_github
  UD-Viz_github-->|split|itownsFork_github
  UD-Viz_github-->|split|utils_github

  core-->widgets
  core-->3DTilesExtensions
  utils_shared-->utils_browser
  utils_shared-->utils_node
  core--->smdb
  game_shared-->game_node
  core--->game_browser
  core-->debug
  game_shared-->game_browser
  utils_browser----->game_browser
  utils_browser-->smdb
  utils_browser-->|?|itowns_packages
  utils_shared-->game_shared
  utils_node-->game_github
  utils_node-->smdb_github

We could choose to not create utils in that case each packages would copy/paste utils function needed

without utils

flowchart TD
  subgraph UD-Viz_github
  end
  subgraph smdb_github
    subgraph smdb_package
      smdb
    end
    subgraph smdb_backend_code
    end
  end
  subgraph game_github
    subgraph game_packages
      game_shared
      game_browser
      game_node
    end
  end
  subgraph itownsFork_github
    subgraph itowns_packages
      core
      debug
      widgets
      3DTilesExtensions
    end
  end

  UD-Viz_github-->|split|smdb_github
  UD-Viz_github-->|split|game_github
  UD-Viz_github-->|split|itownsFork_github

  core-->widgets
  core-->3DTilesExtensions
  core--->smdb
  game_shared-->game_node
  core--->game_browser
  core-->debug
  game_shared-->game_browser

[valentinMachado]

what UD-Viz-template would become (iTowns-template ?) within this target package architecture

yes it could a good idea to propose a project template not on ud-viz but with itowns

what a new VCity application would look like (import @itowns/xxx and @udviz/yyy packages)

the package.json should looks like this:

{
 dependency:{
  @itowns/core:xxx, // core package
  @itowns/...:xxx, // packages extending itowns (living in the itowns mono repo)
  smdb_like_package:xxx // packages extending itowns but living aside their backend code
  ...
  other_packages:xxx 
 }
}

[valentinMachado]

SInce #735 is merged what's need to be done in this issue ?