VCityTeam
Re-unite UD-Viz with iTowns (or let it die?)
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)
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
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
}
}