Change Details

Initial steps to take in order to define the strategy as agreed on 2020-06-09 1. To allow for easier identification of dependencies and interdependencies in PHP code, all Wikibase classes are to moved/adjusted to PSR-4-compliant namespaces. This is expected to make reasoning about the PHP classes easier. 2. Create an overview of existing types of coupling between Repo and Client, including details on problematic aspects Possibly incomplete list of known types * Coupling in PHP code * Coupling in the front end code * Coupling of i18n messages used in both places * Coupling of ResourceLoader modules used in both places * Coupling in cache layer (shared cache entries in WMF environment?) * Coupling in data access layer 3. Explore the monorepo solution for maintaining shared logic. Consider not only PHP, but also Front end code - both legacy and new vuejs logic. Possibly also shared i18n messages and ResourceLoader module definitions. 4. Create a draft of using WikibaseClient extension as an interim platform to share logic between Client and Repo. It should be accounted for not allowing to share PHP code but only other shared logic (i18n messages, RL modules)

Initial steps to take in order to define the strategy as agreed on 2020-06-09 1. To allow for easier identification of dependencies and interdependencies in PHP code, all Wikibase classes are to moved/adjusted to PSR-4-compliant namespaces. This is expected to make reasoning about the PHP classes easier. For bookkeeping reasons, T172368 will be used to track this activity. 2. Create an overview of existing types of coupling between Repo and Client, including details on problematic aspects Possibly incomplete list of known types * Coupling in PHP code * Coupling in the front end code * Coupling of i18n messages used in both places * Coupling of ResourceLoader modules used in both places * Coupling in cache layer (shared cache entries in WMF environment?) * Coupling in data access layer 3. Explore the monorepo solution for maintaining shared logic. Consider not only PHP, but also Front end code - both legacy and new vuejs logic. Possibly also shared i18n messages and ResourceLoader module definitions. 4. Create a draft of using WikibaseClient extension as an interim platform to share logic between Client and Repo. It should be accounted for not allowing to share PHP code but only other shared logic (i18n messages, RL modules)

Initial steps to take in order to define the strategy as agreed on 2020-06-09 1. To allow for easier identification of dependencies and interdependencies in PHP code, all Wikibase classes are to moved/adjusted to PSR-4-compliant namespaces. This is expected to make reasoning about the PHP classes easier. For bookkeeping reasons, T172368 will be used to track this activity. 2. Create an overview of existing types of coupling between Repo and Client, including details on problematic aspects Possibly incomplete list of known types * Coupling in PHP code * Coupling in the front end code * Coupling of i18n messages used in both places * Coupling of ResourceLoader modules used in both places * Coupling in cache layer (shared cache entries in WMF environment?) * Coupling in data access layer 3. Explore the monorepo solution for maintaining shared logic. Consider not only PHP, but also Front end code - both legacy and new vuejs logic. Possibly also shared i18n messages and ResourceLoader module definitions. 4. Create a draft of using WikibaseClient extension as an interim platform to share logic between Client and Repo. It should be accounted for not allowing to share PHP code but only other shared logic (i18n messages, RL modules)