On Wed, Feb 4, 2015 at 2:33 AM, Erik Moeller erik@wikimedia.org wrote:
If not, then I think one thing to keep in mind is how to organize the transformation code in a manner that it doesn't just become a server-side hodgepodge still only useful to one consumer, to avoid some of the pitfalls Brian mentions.
I think the MobileFrontend extension has probably run into these pitfalls already.
Say you want to reformat infoboxes on the mobile web, but not do all the other stuff the mobile app does. Can you just get that specific transformation? Are some transformations dependent on others? Or say we want to make a change only for the output that gets fed into the PDF generator, but not for any other outputs. Can we do that?
Maybe what we really need is a way to register transformation classes (e.g. something like $wgAPIModules). Then have ApiParse have a parameter to select transformations and apply them to wikitext before and to HTML after calling the parser. And we'd probably want to do the wikitext-before bit in ApiExpandTemplates too, and add a new action that takes HTML and applies only the HTML-after transforms to it.
Or we could go as far as giving ParserOptions (or the ParserEnvironment I recently heard Tim propose) a list of transformations, to allow for transformations at some of the points where we have parser hooks. Although that would probably cause problems for Parsoid.
TL;DR; this discussion is great, but I think moving to docs/wikis/etc. instead of continuing the thread could improve communication and give the people who end up working on this something to reference later. could just be my n00b-ness, but I thought others might share the sentiment.
I'm still new here, so please excuse me for possibly going against convention, but does anyone else think it would be beneficial to move this problem & proposal into a living document (RFC, wiki, google doc, whatever)? In doing so, I hope we can:
1. Keep track of what the actual problems are along with the proposed solution(s) 2. Group related concerns together, making them easier for those voicing them to be heard while also facilitating understanding and resolution 3. Give us something concrete to go back to whenever we decide to dedicate resources to solving this problem, whether it's the next mobile apps sprint or something the mobile web team needs more urgently 4. Prevent the points raised in the email (or the problem itself) from being forgotten or lost in the deluge of other emails we get every day
I don't know about you, but I can't mentally juggle the multiple problems, implications, and the great points everyone is raising—which keeping it in an email forces me to do.
Either way, looking forward to discussing this further and taking steps to solve it in the near term.
- Brian
On Wed, Feb 4, 2015 at 10:22 AM, Brad Jorsch (Anomie) <bjorsch@wikimedia.org
wrote:
On Wed, Feb 4, 2015 at 2:33 AM, Erik Moeller erik@wikimedia.org wrote:
If not, then I think one thing to keep in mind is how to organize the transformation code in a manner that it doesn't just become a server-side hodgepodge still only useful to one consumer, to avoid some of the pitfalls Brian mentions.
I think the MobileFrontend extension has probably run into these pitfalls already.
Say you want to reformat infoboxes on the mobile web, but not do all the other stuff the mobile app does. Can you just get that specific transformation? Are some transformations dependent on others? Or say we want to make a change only for the output that gets fed into the PDF generator, but not for any other outputs. Can we do that?
Maybe what we really need is a way to register transformation classes (e.g. something like $wgAPIModules). Then have ApiParse have a parameter to select transformations and apply them to wikitext before and to HTML after calling the parser. And we'd probably want to do the wikitext-before bit in ApiExpandTemplates too, and add a new action that takes HTML and applies only the HTML-after transforms to it.
Or we could go as far as giving ParserOptions (or the ParserEnvironment I recently heard Tim propose) a list of transformations, to allow for transformations at some of the points where we have parser hooks. Although that would probably cause problems for Parsoid.
-- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Feb 4, 2015 at 8:51 AM, Brian Gerstle bgerstle@wikimedia.org wrote:
TL;DR; this discussion is great, but I think moving to docs/wikis/etc. instead of continuing the thread could improve communication and give the people who end up working on this something to reference later. could just be my n00b-ness, but I thought others might share the sentiment.
I'm still new here, so please excuse me for possibly going against convention, but does anyone else think it would be beneficial to move this problem & proposal into a living document (RFC, wiki, google doc, whatever)? In doing so, I hope we can:
- Keep track of what the actual problems are along with the proposed
solution(s) 2. Group related concerns together, making them easier for those voicing them to be heard while also facilitating understanding and resolution 3. Give us something concrete to go back to whenever we decide to dedicate resources to solving this problem, whether it's the next mobile apps sprint or something the mobile web team needs more urgently 4. Prevent the points raised in the email (or the problem itself) from being forgotten or lost in the deluge of other emails we get every day
I don't know about you, but I can't mentally juggle the multiple problems, implications, and the great points everyone is raising—which keeping it in an email forces me to do.
Either way, looking forward to discussing this further and taking steps to solve it in the near term.
+1 This sort of major design change is exactly the sort of thing that I think the RfC process is good at helping with. Start with a straw man proposal, get feedback from other engineers and iterate before investing in code changes. The sometime frustrating part is that feedback doesn't always come as fast as Product and/or the team would like but we can try to accelerate that by promoting the topic more often.
Bryan
On 4 February 2015 at 08:40, Bryan Davis bd808@wikimedia.org wrote:
+1 This sort of major design change is exactly the sort of thing that I think the RfC process is good at helping with. Start with a straw man proposal, get feedback from other engineers and iterate before investing in code changes. The sometime frustrating part is that feedback doesn't always come as fast as Product and/or the team would like but we can try to accelerate that by promoting the topic more often.
Our plan is to have a spike to experiment to determine whether there are any early roadblocks in the proposed solution. We're not going to consider commiting to the RESTBase/Node.js path until after that. It seems quite reasonable to me to also have an RfC alongside our experimentation to try to think up alternative solutions, and invest in experimenting with those solutions too, because we're definitely open to anything that helps us move forwards at this stage.
We'll start writing up an RfC and see where it takes us.
Dan
wikitech-l@lists.wikimedia.org