I did a quick spike [1] to work out how Gather could stop depending on MobileFrontend.
Essentially problems come into 2 categories:
1) Finding a place for Gather in the desktop skin and addressing styling issues in desktop skins (I am working on these and don't see any major blockers here). I think to fix this we simply need to provide Gather as a desktop beta feature. This is tracked here: https://phabricator.wikimedia.org/T95227 and I see no issues with doing this.
2) frontend code standardisation The main problem with the hard dependency is that MobileFrontend uses a library that was built around the same time as OOJSUI. Migrating MobileFrontend to use OOJSUI is a big task and although has happened somewhat (the codebase now uses OOJS for class inheritance) it is by no means complete.
Gather current depends on a variety of MobileFrontend modules which mainly include: API, overlay, user and user setting code, EventLogging schema code, notifications code. We also have a method mw.mobileFrontend.require and mw.mobileFrontend.define for defining modules. OOJS ui does this differently writing class names to the OO global variable object.
==The long term fix=== ... is obviously to migrate all the code to OOJS UI which I believe would require the following steps: * https://phabricator.wikimedia.org/T88559 which as an end result will rewrite overlay code in oojs ui * Rewriting mw.util.notify as an oo js ui component and folding the mobile toast notification into it. - https://phabricator.wikimedia.org/T66565 * Core should have a way to store user settings in localStorage rather than using $.cookie (similar to M.require( 'settings' ) ) - something akin to https://phabricator.wikimedia.org/T67008 * EventLogging Schema.js should be ported to oojs ui and moved into core. * We only use user for the getEditCount function - it would be trivial to rewrite using mw.user
== the short term fix== We could split out the frontend library MobileFrontend uses to allow us to share it between Gather and MobileFrontend.
The way I see this working is to merge all the shared generic JS code into its own project just like oojs ui and slowly rewrite it there till it is pure oo js ui. This would take everything in the javascripts/common/ folder except application.js and bundle it into one file.
We could include this as a submodule in both projects, both extensions conditionally adding a RL module for it when it does not exist.
What do people think about taking this approach on the short term?
Essentially, does that mean we want to re-create Mantle? If so, we should consider the reasons why we dismantled it.
On Apr 13, 2015, at 3:10 PM, Jon Robson jrobson@wikimedia.org wrote:
I did a quick spike [1] to work out how Gather could stop depending on MobileFrontend.
Essentially problems come into 2 categories:
- Finding a place for Gather in the desktop skin and addressing
styling issues in desktop skins (I am working on these and don't see any major blockers here). I think to fix this we simply need to provide Gather as a desktop beta feature. This is tracked here: https://phabricator.wikimedia.org/T95227 and I see no issues with doing this.
- frontend code standardisation
The main problem with the hard dependency is that MobileFrontend uses a library that was built around the same time as OOJSUI. Migrating MobileFrontend to use OOJSUI is a big task and although has happened somewhat (the codebase now uses OOJS for class inheritance) it is by no means complete.
Gather current depends on a variety of MobileFrontend modules which mainly include: API, overlay, user and user setting code, EventLogging schema code, notifications code. We also have a method mw.mobileFrontend.require and mw.mobileFrontend.define for defining modules. OOJS ui does this differently writing class names to the OO global variable object.
==The long term fix=== ... is obviously to migrate all the code to OOJS UI which I believe would require the following steps:
- https://phabricator.wikimedia.org/T88559 which as an end result will
rewrite overlay code in oojs ui
- Rewriting mw.util.notify as an oo js ui component and folding the
mobile toast notification into it. - https://phabricator.wikimedia.org/T66565
- Core should have a way to store user settings in localStorage rather
than using $.cookie (similar to M.require( 'settings' ) ) - something akin to https://phabricator.wikimedia.org/T67008
- EventLogging Schema.js should be ported to oojs ui and moved into core.
- We only use user for the getEditCount function - it would be trivial
to rewrite using mw.user
== the short term fix== We could split out the frontend library MobileFrontend uses to allow us to share it between Gather and MobileFrontend.
The way I see this working is to merge all the shared generic JS code into its own project just like oojs ui and slowly rewrite it there till it is pure oo js ui. This would take everything in the javascripts/common/ folder except application.js and bundle it into one file.
We could include this as a submodule in both projects, both extensions conditionally adding a RL module for it when it does not exist.
What do people think about taking this approach on the short term?
[1] https://phabricator.wikimedia.org/T94100
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
No. Explicitly not. This would just be folding our code out into a sub module. The point is to remove dependencies! :)
We dismantled it because code for templating when into core. On 13 Apr 2015 12:41 pm, "Bahodir Mansurov" bmansurov@wikimedia.org wrote:
Essentially, does that mean we want to re-create Mantle? If so, we should consider the reasons why we dismantled it.
On Apr 13, 2015, at 3:10 PM, Jon Robson jrobson@wikimedia.org wrote:
I did a quick spike [1] to work out how Gather could stop depending on MobileFrontend.
Essentially problems come into 2 categories:
- Finding a place for Gather in the desktop skin and addressing
styling issues in desktop skins (I am working on these and don't see any major blockers here). I think to fix this we simply need to provide Gather as a desktop beta
feature.
This is tracked here: https://phabricator.wikimedia.org/T95227 and I see no issues with doing this.
- frontend code standardisation
The main problem with the hard dependency is that MobileFrontend uses a library that was built around the same time as OOJSUI. Migrating MobileFrontend to use OOJSUI is a big task and although has happened somewhat (the codebase now uses OOJS for class inheritance) it is by no means complete.
Gather current depends on a variety of MobileFrontend modules which mainly include: API, overlay, user and user setting code, EventLogging schema code, notifications code. We also have a method mw.mobileFrontend.require and mw.mobileFrontend.define for defining modules. OOJS ui does this differently writing class names to the OO global variable object.
==The long term fix=== ... is obviously to migrate all the code to OOJS UI which I believe would require the following steps:
- https://phabricator.wikimedia.org/T88559 which as an end result will
rewrite overlay code in oojs ui
- Rewriting mw.util.notify as an oo js ui component and folding the
mobile toast notification into it. - https://phabricator.wikimedia.org/T66565
- Core should have a way to store user settings in localStorage rather
than using $.cookie (similar to M.require( 'settings' ) ) - something akin to https://phabricator.wikimedia.org/T67008
- EventLogging Schema.js should be ported to oojs ui and moved into core.
- We only use user for the getEditCount function - it would be trivial
to rewrite using mw.user
== the short term fix== We could split out the frontend library MobileFrontend uses to allow us to share it between Gather and MobileFrontend.
The way I see this working is to merge all the shared generic JS code into its own project just like oojs ui and slowly rewrite it there till it is pure oo js ui. This would take everything in the javascripts/common/ folder except application.js and bundle it into one file.
We could include this as a submodule in both projects, both extensions conditionally adding a RL module for it when it does not exist.
What do people think about taking this approach on the short term?
[1] https://phabricator.wikimedia.org/T94100
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
I don't see many advantages between the sub-module approach and just leaving it in MobileFrontend and have Gather depend passively on a part of MobileFrontend. I mean, the isolation can make us think that they are decoupled but in reality they will still be highly coupled, and we'll need to be as careful.
It may help differentiate where Gather actually depends on MF and where it depends on this base library, which could be useful to identify and remove MF dependencies. Besides that, I don't see much else.
Jon could you please elaborate on the advantages please?
On Mon, Apr 13, 2015 at 9:44 PM, Jon Robson jrobson@wikimedia.org wrote:
No. Explicitly not. This would just be folding our code out into a sub module. The point is to remove dependencies! :)
We dismantled it because code for templating when into core. On 13 Apr 2015 12:41 pm, "Bahodir Mansurov" bmansurov@wikimedia.org wrote:
Essentially, does that mean we want to re-create Mantle? If so, we should consider the reasons why we dismantled it.
On Apr 13, 2015, at 3:10 PM, Jon Robson jrobson@wikimedia.org wrote:
I did a quick spike [1] to work out how Gather could stop depending on MobileFrontend.
Essentially problems come into 2 categories:
- Finding a place for Gather in the desktop skin and addressing
styling issues in desktop skins (I am working on these and don't see any major blockers here). I think to fix this we simply need to provide Gather as a desktop beta
feature.
This is tracked here: https://phabricator.wikimedia.org/T95227 and I see no issues with doing this.
- frontend code standardisation
The main problem with the hard dependency is that MobileFrontend uses a library that was built around the same time as OOJSUI. Migrating MobileFrontend to use OOJSUI is a big task and although has happened somewhat (the codebase now uses OOJS for class inheritance) it is by no means complete.
Gather current depends on a variety of MobileFrontend modules which mainly include: API, overlay, user and user setting code, EventLogging schema code, notifications code. We also have a method mw.mobileFrontend.require and mw.mobileFrontend.define for defining modules. OOJS ui does this differently writing class names to the OO global variable object.
==The long term fix=== ... is obviously to migrate all the code to OOJS UI which I believe would require the following steps:
- https://phabricator.wikimedia.org/T88559 which as an end result will
rewrite overlay code in oojs ui
- Rewriting mw.util.notify as an oo js ui component and folding the
mobile toast notification into it. - https://phabricator.wikimedia.org/T66565
- Core should have a way to store user settings in localStorage rather
than using $.cookie (similar to M.require( 'settings' ) ) - something akin to https://phabricator.wikimedia.org/T67008
- EventLogging Schema.js should be ported to oojs ui and moved into
core.
- We only use user for the getEditCount function - it would be trivial
to rewrite using mw.user
== the short term fix== We could split out the frontend library MobileFrontend uses to allow us to share it between Gather and MobileFrontend.
The way I see this working is to merge all the shared generic JS code into its own project just like oojs ui and slowly rewrite it there till it is pure oo js ui. This would take everything in the javascripts/common/ folder except application.js and bundle it into one file.
We could include this as a submodule in both projects, both extensions conditionally adding a RL module for it when it does not exist.
What do people think about taking this approach on the short term?
[1] https://phabricator.wikimedia.org/T94100
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
I agree with Joaquin. What are the benefits of decoupling?
On Wednesday, April 15, 2015, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
I don't see many advantages between the sub-module approach and just leaving it in MobileFrontend and have Gather depend passively on a part of MobileFrontend. I mean, the isolation can make us think that they are decoupled but in reality they will still be highly coupled, and we'll need to be as careful.
It may help differentiate where Gather actually depends on MF and where it depends on this base library, which could be useful to identify and remove MF dependencies. Besides that, I don't see much else.
Jon could you please elaborate on the advantages please?
On Mon, Apr 13, 2015 at 9:44 PM, Jon Robson <jrobson@wikimedia.org javascript:_e(%7B%7D,'cvml','jrobson@wikimedia.org');> wrote:
No. Explicitly not. This would just be folding our code out into a sub module. The point is to remove dependencies! :)
We dismantled it because code for templating when into core. On 13 Apr 2015 12:41 pm, "Bahodir Mansurov" <bmansurov@wikimedia.org javascript:_e(%7B%7D,'cvml','bmansurov@wikimedia.org');> wrote:
Essentially, does that mean we want to re-create Mantle? If so, we should consider the reasons why we dismantled it.
On Apr 13, 2015, at 3:10 PM, Jon Robson <jrobson@wikimedia.org
javascript:_e(%7B%7D,'cvml','jrobson@wikimedia.org');> wrote:
I did a quick spike [1] to work out how Gather could stop depending on MobileFrontend.
Essentially problems come into 2 categories:
- Finding a place for Gather in the desktop skin and addressing
styling issues in desktop skins (I am working on these and don't see any major blockers here). I think to fix this we simply need to provide Gather as a desktop beta
feature.
This is tracked here: https://phabricator.wikimedia.org/T95227 and I see no issues with doing this.
- frontend code standardisation
The main problem with the hard dependency is that MobileFrontend uses a library that was built around the same time as OOJSUI. Migrating MobileFrontend to use OOJSUI is a big task and although has happened somewhat (the codebase now uses OOJS for class inheritance) it is by no means complete.
Gather current depends on a variety of MobileFrontend modules which mainly include: API, overlay, user and user setting code, EventLogging schema code, notifications code. We also have a method mw.mobileFrontend.require and mw.mobileFrontend.define for defining modules. OOJS ui does this differently writing class names to the OO global variable object.
==The long term fix=== ... is obviously to migrate all the code to OOJS UI which I believe would require the following steps:
- https://phabricator.wikimedia.org/T88559 which as an end result will
rewrite overlay code in oojs ui
- Rewriting mw.util.notify as an oo js ui component and folding the
mobile toast notification into it. - https://phabricator.wikimedia.org/T66565
- Core should have a way to store user settings in localStorage rather
than using $.cookie (similar to M.require( 'settings' ) ) - something akin to https://phabricator.wikimedia.org/T67008
- EventLogging Schema.js should be ported to oojs ui and moved into
core.
- We only use user for the getEditCount function - it would be trivial
to rewrite using mw.user
== the short term fix== We could split out the frontend library MobileFrontend uses to allow us to share it between Gather and MobileFrontend.
The way I see this working is to merge all the shared generic JS code into its own project just like oojs ui and slowly rewrite it there till it is pure oo js ui. This would take everything in the javascripts/common/ folder except application.js and bundle it into one file.
We could include this as a submodule in both projects, both extensions conditionally adding a RL module for it when it does not exist.
What do people think about taking this approach on the short term?
[1] https://phabricator.wikimedia.org/T94100
Mobile-l mailing list Mobile-l@lists.wikimedia.org
javascript:_e(%7B%7D,'cvml','Mobile-l@lists.wikimedia.org');
Mobile-l mailing list Mobile-l@lists.wikimedia.org javascript:_e(%7B%7D,'cvml','Mobile-l@lists.wikimedia.org'); https://lists.wikimedia.org/mailman/listinfo/mobile-l
Given that your target audience for this project right now is Wikipedia readers, what are the advantages to those users of removing the MobileFrontend dependency from Gather? I'm unclear on this point right now.
Dan
On 13 April 2015 at 12:10, Jon Robson jrobson@wikimedia.org wrote:
I did a quick spike [1] to work out how Gather could stop depending on MobileFrontend.
Essentially problems come into 2 categories:
- Finding a place for Gather in the desktop skin and addressing
styling issues in desktop skins (I am working on these and don't see any major blockers here). I think to fix this we simply need to provide Gather as a desktop beta feature. This is tracked here: https://phabricator.wikimedia.org/T95227 and I see no issues with doing this.
- frontend code standardisation
The main problem with the hard dependency is that MobileFrontend uses a library that was built around the same time as OOJSUI. Migrating MobileFrontend to use OOJSUI is a big task and although has happened somewhat (the codebase now uses OOJS for class inheritance) it is by no means complete.
Gather current depends on a variety of MobileFrontend modules which mainly include: API, overlay, user and user setting code, EventLogging schema code, notifications code. We also have a method mw.mobileFrontend.require and mw.mobileFrontend.define for defining modules. OOJS ui does this differently writing class names to the OO global variable object.
==The long term fix=== ... is obviously to migrate all the code to OOJS UI which I believe would require the following steps:
- https://phabricator.wikimedia.org/T88559 which as an end result will
rewrite overlay code in oojs ui
- Rewriting mw.util.notify as an oo js ui component and folding the
mobile toast notification into it. - https://phabricator.wikimedia.org/T66565
- Core should have a way to store user settings in localStorage rather
than using $.cookie (similar to M.require( 'settings' ) ) - something akin to https://phabricator.wikimedia.org/T67008
- EventLogging Schema.js should be ported to oojs ui and moved into core.
- We only use user for the getEditCount function - it would be trivial
to rewrite using mw.user
== the short term fix== We could split out the frontend library MobileFrontend uses to allow us to share it between Gather and MobileFrontend.
The way I see this working is to merge all the shared generic JS code into its own project just like oojs ui and slowly rewrite it there till it is pure oo js ui. This would take everything in the javascripts/common/ folder except application.js and bundle it into one file.
We could include this as a submodule in both projects, both extensions conditionally adding a RL module for it when it does not exist.
What do people think about taking this approach on the short term?
[1] https://phabricator.wikimedia.org/T94100
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
I think it is a technical detail Moiz and Dan, no decoupling from the wikipedia ecosystem.
The idea (I think) is to make Gather more independent of Mobile frontend so that it can work seamlessly in Desktop when the time comes and in the way extract valuable common code into library/core so that other extensions can benefit from it too and MobileFrontend becomes leaner, cleaner and more focused.
Gather will still be embedded on mediawiki as a extension and will use mobilefrontend and core as it needs.
Correct me Jon If I'm wrong.
On Wed, Apr 15, 2015 at 8:13 PM, Dan Garry dgarry@wikimedia.org wrote:
Given that your target audience for this project right now is Wikipedia readers, what are the advantages to those users of removing the MobileFrontend dependency from Gather? I'm unclear on this point right now.
Dan
On 13 April 2015 at 12:10, Jon Robson jrobson@wikimedia.org wrote:
I did a quick spike [1] to work out how Gather could stop depending on MobileFrontend.
Essentially problems come into 2 categories:
- Finding a place for Gather in the desktop skin and addressing
styling issues in desktop skins (I am working on these and don't see any major blockers here). I think to fix this we simply need to provide Gather as a desktop beta feature. This is tracked here: https://phabricator.wikimedia.org/T95227 and I see no issues with doing this.
- frontend code standardisation
The main problem with the hard dependency is that MobileFrontend uses a library that was built around the same time as OOJSUI. Migrating MobileFrontend to use OOJSUI is a big task and although has happened somewhat (the codebase now uses OOJS for class inheritance) it is by no means complete.
Gather current depends on a variety of MobileFrontend modules which mainly include: API, overlay, user and user setting code, EventLogging schema code, notifications code. We also have a method mw.mobileFrontend.require and mw.mobileFrontend.define for defining modules. OOJS ui does this differently writing class names to the OO global variable object.
==The long term fix=== ... is obviously to migrate all the code to OOJS UI which I believe would require the following steps:
- https://phabricator.wikimedia.org/T88559 which as an end result will
rewrite overlay code in oojs ui
- Rewriting mw.util.notify as an oo js ui component and folding the
mobile toast notification into it. - https://phabricator.wikimedia.org/T66565
- Core should have a way to store user settings in localStorage rather
than using $.cookie (similar to M.require( 'settings' ) ) - something akin to https://phabricator.wikimedia.org/T67008
- EventLogging Schema.js should be ported to oojs ui and moved into core.
- We only use user for the getEditCount function - it would be trivial
to rewrite using mw.user
== the short term fix== We could split out the frontend library MobileFrontend uses to allow us to share it between Gather and MobileFrontend.
The way I see this working is to merge all the shared generic JS code into its own project just like oojs ui and slowly rewrite it there till it is pure oo js ui. This would take everything in the javascripts/common/ folder except application.js and bundle it into one file.
We could include this as a submodule in both projects, both extensions conditionally adding a RL module for it when it does not exist.
What do people think about taking this approach on the short term?
[1] https://phabricator.wikimedia.org/T94100
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Exactly. Purely technical. From an outsiders perspective it makes little difference - the feature will still look and behave the same.. To be honest the easiest thing to do would be to package our code and put it in core, which is what VisualEditor did with oojs ui - but having two libraries side by side would confuse people.
To be honest, I'm still not 100% sure it's the right thing to do. I think a better strategy would be to slowly rewrite to oojsui until a point we can simply depend on components in the oojs ui library that is in core. It's just this is a long long long long long way away and I'm desperate to find some sort of middle ground :(
tdlr: Benefits: * As Joaquin says - forces us to work out what code is MF is important as a base library * Forces us to coordinate releases between Wikigrok, MobileFrontend and Gather as if extensions are on a different submodule version, stuff can break dramatically. * Having the code in a separate space makes it easier for us to rewrite it in oojs ui * Will save us time trying to explain to people that Gather is not mobile only - which seems to be a common theme, from people seeing the extension depends on MobileFrontend... which is simply not true. We've wasted a lot of man hours arguing this point.
I'm talking to people about working to break VisualEditor mobile experience out of MobileFrontend and move it into VisualEditor. I think this will be very catalysing and help us in many ways, hopefully with this dependency on the long term.
On Wed, Apr 15, 2015 at 11:29 AM, Joaquin Oltra Hernandez jhernandez@wikimedia.org wrote:
I think it is a technical detail Moiz and Dan, no decoupling from the wikipedia ecosystem.
The idea (I think) is to make Gather more independent of Mobile frontend so that it can work seamlessly in Desktop when the time comes and in the way extract valuable common code into library/core so that other extensions can benefit from it too and MobileFrontend becomes leaner, cleaner and more focused.
Gather will still be embedded on mediawiki as a extension and will use mobilefrontend and core as it needs.
Correct me Jon If I'm wrong.
On Wed, Apr 15, 2015 at 8:13 PM, Dan Garry dgarry@wikimedia.org wrote:
Given that your target audience for this project right now is Wikipedia readers, what are the advantages to those users of removing the MobileFrontend dependency from Gather? I'm unclear on this point right now.
Dan
On 13 April 2015 at 12:10, Jon Robson jrobson@wikimedia.org wrote:
I did a quick spike [1] to work out how Gather could stop depending on MobileFrontend.
Essentially problems come into 2 categories:
- Finding a place for Gather in the desktop skin and addressing
styling issues in desktop skins (I am working on these and don't see any major blockers here). I think to fix this we simply need to provide Gather as a desktop beta feature. This is tracked here: https://phabricator.wikimedia.org/T95227 and I see no issues with doing this.
- frontend code standardisation
The main problem with the hard dependency is that MobileFrontend uses a library that was built around the same time as OOJSUI. Migrating MobileFrontend to use OOJSUI is a big task and although has happened somewhat (the codebase now uses OOJS for class inheritance) it is by no means complete.
Gather current depends on a variety of MobileFrontend modules which mainly include: API, overlay, user and user setting code, EventLogging schema code, notifications code. We also have a method mw.mobileFrontend.require and mw.mobileFrontend.define for defining modules. OOJS ui does this differently writing class names to the OO global variable object.
==The long term fix=== ... is obviously to migrate all the code to OOJS UI which I believe would require the following steps:
- https://phabricator.wikimedia.org/T88559 which as an end result will
rewrite overlay code in oojs ui
- Rewriting mw.util.notify as an oo js ui component and folding the
mobile toast notification into it. - https://phabricator.wikimedia.org/T66565
- Core should have a way to store user settings in localStorage rather
than using $.cookie (similar to M.require( 'settings' ) ) - something akin to https://phabricator.wikimedia.org/T67008
- EventLogging Schema.js should be ported to oojs ui and moved into core.
- We only use user for the getEditCount function - it would be trivial
to rewrite using mw.user
== the short term fix== We could split out the frontend library MobileFrontend uses to allow us to share it between Gather and MobileFrontend.
The way I see this working is to merge all the shared generic JS code into its own project just like oojs ui and slowly rewrite it there till it is pure oo js ui. This would take everything in the javascripts/common/ folder except application.js and bundle it into one file.
We could include this as a submodule in both projects, both extensions conditionally adding a RL module for it when it does not exist.
What do people think about taking this approach on the short term?
[1] https://phabricator.wikimedia.org/T94100
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l