[14:54:43] <RhinosF1>	 Is the Grants meeting still running in 5 mins?
[14:56:59] <i_jethrobot>	 @RhinoF1 Yes, that's correct. : )
[14:57:37] <RhinosF1>	 i_jethrobot: I don't have any grants but I may listen in since it's technical and should be interesting
[14:58:20] <i_jethrobot>	 @RhinosF1 Sure, you'd be welcome to listen in or ask any questions you might have.
[14:58:40] <RhinosF1>	 This will be my first non-irc meeting as well!
[14:58:52] <i_jethrobot>	 Hi folks, this is Chris Schilling, one of the program officers for Wikimedia Foundation's Project Grants program. We have a proposal workshop focused on technical projects starting in just a few minutes. Please feel free to leave questions about your proposal or about grant program here, and I'll be sure to respond over the next hour.
[14:59:00] * andre__ waves
[14:59:23] <i_jethrobot>	 @andre__ will be joining us as well. : D
[14:59:33] * RhinosF1 waves
[14:59:44] <i_jethrobot>	 IF you want to join the call on Google Hangouts, please feel free to do so here: http://meet.google.com/msg-yxfb-syr
[14:59:56] <RhinosF1>	 I'm waiting to be let in
[15:00:00] <i_jethrobot>	 er, Google Meet. Whatever they are calling it these days.
[15:00:11] <RhinosF1>	 Meet it says
[15:56:58] <RhinosF1>	 i_jethrobot: sorry, had to run to get a laptop charger
[15:57:34] <i_jethrobot>	 RhinosF1: no problem, I've defintely been there before in the middle of a call : )
[15:57:46] <RhinosF1>	 :)
[16:00:37] <RhinosF1>	 That was fun :)
[16:01:43] <RhinosF1>	 I'll have to see where else I can show up
[16:15:01] <i_jethrobot>	 Hi everyone, the proposal workshop has ended. There is one more proposal workshop later today on GLAM-related projects, so feel free to join if you are interested: https://meta.wikimedia.org/wiki/Grants:Project#Upcoming_events
[16:15:22] <i_jethrobot>	 RhinosF1: Thanks for joining us!
[16:16:16] <RhinosF1>	 i_jethrobot: no problem, Thanks for hosting! It was a great first non-irc meeting.
[16:53:12] <hueitan>	 fa
[19:59:13] <i_jethrobot>	 Hi folks, this is Chris Schilling, one of the program officers for Wikimedia Foundation's Project Grants program. We have a proposal workshop focused on GLAM-related projects starting soon. Please feel free to leave questions about your proposal or about grant program here, and I'll be sure to respond over the next hour.
[19:59:41] <i_jethrobot>	 If you want to join the call on Google Hangouts, please feel free to do so here: http://meet.google.com/aqd-thbi-ris
[20:00:18] <i_jethrobot>	 We will also be joined by Sanda Fauconnier, Program Officer for GLAM and Structured Data.
[21:55:32] <KateChapman>	 hi! the RFC IRC meeting about the RFC to Adopt a modern JavaScript framework is going to start in 5 minutes. https://phabricator.wikimedia.org/T241180
[21:56:00] * James_F has nothing to say except "good work".
[21:57:19] <niedzielski>	 hey all
[21:58:18] <EricGardner>	 hi all – I apologize in advance for not really understanding how to use IRC
[21:58:48] <KateChapman>	 EricGardner: you got a message across, I'd say you understand it well enough
[21:59:27] <EricGardner>	 that was more than I was able to do last time – I could type but no one could see me. I just thought I was being ignored!
[22:00:11] <KateChapman>	 #startmeeting
[22:00:34] <KateChapman>	 hmmm so that didn't work
[22:00:53] <RoanKattouw>	 Looks like the bot might be down?
[22:00:54] <KateChapman>	 TimStarling: are you around for the regular kicking of the bot?
[22:01:04] <TimStarling>	 yes
[22:01:20] <Nikerabbit>	 poor bot being kicked every time
[22:01:41] <KateChapman>	 what sorts of carrots do bots like
[22:02:46] <KateChapman>	 #startmeeting
[22:02:46] <wm-labs-meetbot>	 KateChapman: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee'
[22:03:00] <KateChapman>	 #startmeeting  RFC: Adopt a modern JavaScript framework for use with MediaWiki
[22:03:01] <wm-labs-meetbot>	 Meeting started Wed Feb 19 22:03:00 2020 UTC and is due to finish in 60 minutes.  The chair is KateChapman. Information about MeetBot at http://wiki.debian.org/MeetBot.
[22:03:01] <wm-labs-meetbot>	 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
[22:03:01] <wm-labs-meetbot>	 The meeting name has been set to 'rfc__adopt_a_modern_javascript_framework_for_use_with_mediawiki'
[22:03:19] <KateChapman>	 #link https://phabricator.wikimedia.org/T241180
[22:03:59] <KateChapman>	 okay, let's get started. I wanted to state we'd like to focus on missing requirements in this RFC and any concerns about the current proposed solution
[22:04:41] <KateChapman>	 Those who have doing the initial work. Any discoveries or other information you'd like to share from that?
[22:05:13] <RoanKattouw>	 I can talk a bit about what EricGardner and I did the last two weeks
[22:05:15] <KateChapman>	 (sorry just realized I haven't done this in a long time before we do that. Who is here for the meeting?)
[22:05:26] <KateChapman>	 if you can give me a wave o/
[22:05:28] <niedzielski>	 o/
[22:05:30] <EricGardner>	 o/
[22:05:50] <RoanKattouw>	 o/
[22:05:54] <lucaswerkmeister>	 o/
[22:06:08] <Nikerabbit>	 o
[22:06:24] <KateChapman>	 okay RoanKattouw take it away!
[22:06:49] <RoanKattouw>	 So I started with some simple things that I won't talk much about, including:
[22:07:03] <RoanKattouw>	 Adding the vue.js library to our repo as an external resource: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/569666
[22:07:16] <RoanKattouw>	 (thanks to James_F for cleaning up that commit and doing it properly)
[22:08:20] <RoanKattouw>	 Adding linting for .vue files: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/569677
[22:08:48] <RoanKattouw>	 That both covers linting JS and CSS/LESS inside .vue files, but also linting the HTML templates in .vue files using Vue-specific lint rules (through an eslint plugin)
[22:09:10] <RoanKattouw>	 Adding a simple Vue plugin to bridge to the MW i18n system: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/570500
[22:09:59] <RoanKattouw>	 All those things are already merged, and they're relatively straightforward. They're not 100% done, we'll probably want to tweak the lint rules a bit over time, and we might want to add more features to the i18n plugin, but there are no huge unanswered questions there or anything
[22:10:24] <RoanKattouw>	 The biggest thing I worked on is this patch (not yet merged) that makes .vue files a first-class citizen in ResourceLoader: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/569692
[22:11:04] <RoanKattouw>	 It allows you to include .vue files in package modules, parses them in PHP, and transforms them to JS+CSS
[22:12:08] <RoanKattouw>	 As discussed on the task, this uses the client-side compilation strategy: instead of compiling the template to JS code on the server (which requires running the vue-cli tools), it just encodes the template as a string and sticks it in module.exports.template, which Vue then compiles/interprets on the client
[22:12:43] <RoanKattouw>	 EricGardner made a demonstration extension that shows off these features: https://github.com/egardner/mediawiki-extensions-VueTest
[22:13:01] <RoanKattouw>	 His extension also uses jest to run unit tests on Vue components
[22:14:13] <RoanKattouw>	 I did some limited performance testing, and found that for a language search widget with 400+ languages, Vue was about 10x faster to initialize than OOUI (~80ms vs ~900ms, with 444 vs 588 languages), with comparable performance once initialized
[22:15:06] <RoanKattouw>	 I haven't yet done a proper apples-to-apples comparison (with the same number of languages, and a more complete feature set) of this yet, and I will soon, but the difference is so large that I think we can say that Vue's performance appears to be acceptable and better than OOUI's for this (somewhat pathological) case
[22:15:11] <milimetric>	 including compilation time or did you factor that out?
[22:15:25] <RoanKattouw>	 That includes compilation time, but there wasn't a whole lot to compile
[22:15:51] <KateChapman>	 EricGardner: anything you want to add?
[22:16:21] <EricGardner>	 That extension repo also contains a lot of documentation that may be useful for folks getting started with Vue, and some additional config for linters, test runners, etc that I found useful
[22:16:39] <KateChapman>	 #info EricGardner made a demonstration extension that shows off these features: https://github.com/egardner/mediawiki-extensions-VueTest
[22:16:50] <EricGardner>	 Also, one important limitation of the approach Roan is describing is that JS still needs to be written in ES5
[22:16:51] <KateChapman>	 #info 2:16 PM <EricGardner> That extension repo also contains a lot of documentation that may be useful for folks getting started with Vue, and some additional config for linters, test runners, etc that I found useful
[22:17:04] <KateChapman>	 #info 2:16 PM <EricGardner> Also, one important limitation of the approach Roan is describing is that JS still needs to be written in ES5
[22:17:13] <EricGardner>	 Vue SFCs do support things like LESS compiliation (not SASS though), CSS Janus, etc
[22:17:30] <EricGardner>	 So they basically become a first-class citizen in the mediawiki environment
[22:17:34] <KateChapman>	 btw if you want something in the minutes use the info tag before it. I'm also happy to extract things out by copy/pasting
[22:17:47] <RoanKattouw>	 Yes, that's right. RL support for .vue files integrates with everything that you would expect normal JS and CSS/LESS to be able to do in MW
[22:18:14] <EricGardner>	 For things that rely on global mw objects, Vue plugins are a good solution. We have a simple one for mw.message
[22:18:16] <RoanKattouw>	 So that means you can use LESS variables and imports for example, RTL flipping through CSSJanus, /* @embed */, etc
[22:18:32] <EricGardner>	 my example extension also has a basic example of how you could handle mw.Api the same way
[22:18:32] <RoanKattouw>	 But it also means that you can't use things that aren't otherwise supported in RL, such as ES6
[22:19:17] <RoanKattouw>	 I would like to experiment with integrating Babel with RL some time, but I didn't think that was important enough to focus on for this quick 2-week effort
[22:19:33] <EricGardner>	 Agreed. That's a bigger task for the future
[22:20:22] <Nikerabbit>	 Are there other things besides ES6 that aren't supported yet, but maybe in the future?
[22:20:30] <EricGardner>	 scoped styles
[22:20:41] <EricGardner>	 and server-side rendering of components
[22:21:09] <EricGardner>	 a few other small things – apparently the shorthands for some directives, like @ for v-on and : for v-bind need webpack
[22:21:27] <EricGardner>	 the linter rules in the example repo enforce "longform" usage of the directives for that reason
[22:21:44] <EricGardner>	 But I think that once Roan's patches are merged, we will have good support for using most of Vue's features in a progressive-enhancement, client-side rendered way
[22:21:46] <milimetric>	 aw that’s a shame, @ and : make code much more readable
[22:21:47] <KateChapman>	 #info 2:20 PM <Nikerabbit> Are there other things besides ES6 that aren't supported yet, but maybe in the future?
[22:21:53] <lucaswerkmeister>	 huh, that sounds odd
[22:22:16] <EricGardner>	 I could be wrong. I assumed the vue template compiler would handle those, but I couldn't get them to work
[22:23:07] <RoanKattouw>	 It's possible that VueComponentParser.php mangles them somehow. We'll have to look into it
[22:23:26] <niedzielski>	 Seems like something that could be explored more in the future.
[22:23:28] <RoanKattouw>	 I also have a TODO for seeing if functional templates are supported with client-side compilation, the documentation is unclear on this front
[22:23:29] <EricGardner>	 Also, there are some limitations about how RL processes package files that make some in-browser debugging kind of tricky. This is not vue-specific
[22:23:41] <milimetric>	 I was curious if you’d looked at Vue 3’s new approach using composition
[22:24:26] <EricGardner>	 millimetric: I've been following this but have never used it. I think we can support Vue3 once it is finalized, and see no reason why these features would not work
[22:24:47] <milimetric>	 https://vue-composition-api-rfc.netlify.com/
[22:24:57] <EricGardner>	 supposedly Vue3 will also ship a lot of improvements to the template compiler
[22:25:22] <EricGardner>	 this might improve performance for the kind of usage we're considering (though it already seems pretty good so far)
[22:25:32] <milimetric>	 it might imply different infrastructure and integration with RL, but haven’t thought it through yet
[22:26:07] <EricGardner>	 It seems like the Vue community has been saying the composition API will be there for more complex use cases, but templates should be preferred for most cases
[22:26:37] <EricGardner>	 Similar to writing your own render functions in Vue
[22:28:40] <EricGardner>	 Regarding the composition API, I'm hoping that by relying on Vue's own template compiler to do most of the work, integration with RL won't complicate things too much.
[22:28:59] <KateChapman>	 anyone have any questions?
[22:29:01] <milimetric>	 hm, my intuition is that composition would work well for core/standard extensions and templates for more stand-alone extensions and folks getting started with vue.  I saw a very similar split in the knockout community
[22:29:02] <KateChapman>	 (so far)
[22:30:06] <Nikerabbit>	 Is vue going to be available for gadgets and user scripts? I'd assume the module is loadable, but one couldn't create vue files in the wiki?
[22:31:03] <Krinkle>	 Indeed. The programmatic API will be available initially.
[22:31:09] <Krinkle>	 But that means compilation shortcuts are not.
[22:31:44] <Krinkle>	 I don't know what Vue's normal API looks like, e.g. what <template> compiles to, is that sometimes used in demos or has examples to be human readable, or is that esoteric/internal
[22:32:06] <Krinkle>	 I guess custom render functions would make use of that so presumably public and not too bad.
[22:32:13] <EricGardner>	 Vue compiles templates into a render function, yes
[22:32:13] <RoanKattouw>	 So the normal API is Vue.component( 'component-name', { .... } );
[22:32:36] <RoanKattouw>	 Where { ... } is the module.exports that you see in the <script> tag of the .vue file, plus { template: '<div>....</div>' }
[22:32:43] <EricGardner>	 Really the "normal" API is probably just writing SFCs that import their children, but you have a few different ways to do it
[22:32:50] <Krinkle>	 Would be good to have an example of that on-wiki, both for gadgets, but also for casees where in core/extesion you might need to bypass <template> for perf or other reasons
[22:33:24] <RoanKattouw>	 So the only magic that SFC processing does is stringifying the contents of the <template> tag and putting it in module.exports.template
[22:33:25] <Krinkle>	 EricGardner: do I understand correctly that using  Vue.component() is what it means to write a custom render function?
[22:33:51] <niedzielski>	 I think we should allow the internal solution time to mature a little before encouraging broader usage and best practice that may otherwise be challenging to migrate.
[22:33:52] <RoanKattouw>	 Krinkle: No, a custom render function would be using { render: function ( h ) { .... } } instead of { template: '<div>...</div>' }
[22:33:55] <EricGardner>	 not exactly. When you create a Vue component (or a basic instance that does not have sub components), you can provide template and/or render options
[22:34:08] <EricGardner>	 a render function will supersede a string template
[22:34:12] <Nikerabbit>	 SFC in this context means single file component, right?
[22:34:16] <RoanKattouw>	 Yes
[22:34:18] <EricGardner>	 yes
[22:34:29] <EricGardner>	 There is pretty good documentation on render functions here: https://vuejs.org/v2/guide/render-function.html
[22:34:44] <Krinkle>	 Right, so calling  Vue.component(), as a gadget woudl need to, can still leverage the template syntax.
[22:34:48] <RoanKattouw>	 Yes exactly
[22:34:53] <Krinkle>	 it just makes it more obvious that it is compiled client-side
[22:35:02] <EricGardner>	 Since we are shipping the template compiler in our Vue module, developers will have a lot of options. they can provide a string template inline, use an existing dom element, write a render functions themselves, etc
[22:35:02] <RoanKattouw>	 The Webpack build step that some people have said they want to use does the compilation server-side, and outputs a render function
[22:35:36] <EricGardner>	 This is useful re: different ways to define templates: https://vuejsdevelopers.com/2017/03/24/vue-js-component-templates/
[22:35:47] <lucaswerkmeister>	 and a gadget would have to write the template as 'foo\n' + 'bar\n' + ..., not using `backticks` syntax, because ES5?
[22:37:03] <EricGardner>	 they could provide a <script type="text/x-template"> tag on a page and reference it with an ID, if they are writing a HMTL page
[22:37:22] <EricGardner>	 I don't know a lot about what gadget authors have to work with. Can they define different types of files as part of the gadget?
[22:38:18] <EricGardner>	 ideally they could write single file components with a .vue extension themselves
[22:38:27] <Krinkle>	 of that, they'd have to either use createElement() or use a string literal for template indeed.
[22:40:15] <Nikerabbit>	 I was mostly thinking how hard it will be to update vue in the future, we probably don't need to discuss vue support for gadgets/user scripts deeply yet
[22:41:19] <EricGardner>	 my understanding is that Vue 3 has very few breaking changes and should be a pretty painless upgrade. The basic component APIs are the same, with some new additions like context API
[22:41:37] <Krinkle>	 Yep. This is inherit to any large scale entitity with a framework-based frontend. Anything loaded on a single page needs to upgrade in lockstep. Which means you won't get stuck so long as upstream follows best practices of not making breaking changes other than removal of deprecated functionality so that gradual migration is possible.
[22:41:52] <Krinkle>	 This is followed by jQuery, OOUI, etc. I don't know if Vue has formerly committed to that.
[22:41:54] <milimetric>	 I agree with niedzielski that a well-considered style guide for gadget authors would be wise, perhaps looking at how the migration of gadgets to OOUI could’ve gone better
[22:42:02] <RoanKattouw>	 I haven't explored what it would require to support .vue files directly from gadgets, but it's probably feasible
[22:42:29] <EricGardner>	 I think that a Wikimedia-Vue styleguide should be one of our next priorities here
[22:42:53] <EricGardner>	 since we'll be using Vue in a way that is supported but different (es5, custom module system, etc) from most of the rest of the community
[22:43:03] <lucaswerkmeister>	 can’t different parts of the page load different versions of the framework if they want? e. g. vue2 and vue3 RL modules
[22:43:12] <lucaswerkmeister>	 (as long as neither of them pollutes the global scope)
[22:43:28] <Krinkle>	 #info It is required for our scale and range (core/extensions, multiple orgs/teams, community gadgets) that the framework strictly follow a no-breaking-change rule other than removal of deprecated functionality after replacements are added in a previous release.
[22:43:46] <Nikerabbit>	 that would imply versioning at module name level, right?
[22:43:46] <milimetric>	 is that how we plan on using vue for the medium-term?  Or are we going to tackle the server-side compile problem sooner than later?
[22:44:35] <RoanKattouw>	 lucaswerkmeister: Yes, it looks like that will probably work
[22:44:51] <Krinkle>	 in terms of comparison to OOUI, Vue is taking the place of plain JS and/or jQuery. OOUI as being our component library and style guide indeed needs to be ported and offered in some form or another.
[22:44:54] <KateChapman>	 **** 15 minutes left ****
[22:45:01] <lucaswerkmeister>	 (not something we *want* to have for a long time, of course, loading twice as much code etc)
[22:45:29] <KateChapman>	 milimetric: we haven't gotten into the server side part yet. What does medium-term mean to you?
[22:46:17] <Krinkle>	 milimetric: adoption beyond late/client-side interactions is blocked on a server-side which is part of FAWG's direction but indeed getting the frontend puzzle solved first is the first step.
[22:47:04] <milimetric>	 not server side rendering, but something like a build step to prevent having to ship the compiler to the client and allow using vue for default-rendered UI, was just asking if we’ve got concrete plans to move in that direction or we’re stuck for the reasons that Roan has articulated before (down sides of checking in built artifacts, etc)
[22:47:28] <milimetric>	 got it, thx
[22:47:34] <EricGardner>	 One reason why Vue seemed like the best choice here is that we can start using the new framework now, sans build-step, with a small number of limitations
[22:47:46] <milimetric>	 right, makes sense
[22:47:54] <Krinkle>	 but yeah, I hope that in terms of perf cost that we won't be shipping the compiler for long. as-is that would likely regress performance compared to OOUI.
[22:48:01] <KateChapman>	 I'm trying to raise the importance of the build step to understand the blockers and how we can mitigate them
[22:48:27] <RoanKattouw>	 There's some (older) discussion about build step stuff at T199004
[22:48:27] <stashbot>	 T199004: RFC: Add a frontend build step to skins/extensions to our deploy process - https://phabricator.wikimedia.org/T199004
[22:48:46] <milimetric>	 I would think it’d be good to wait until you do tackle the build step problem before making too final of a style guide and other migration/plans around vue
[22:49:23] <RoanKattouw>	 It's true that server-side complilation of templates will clearly be better for performance, but I'm not sure that it would "likely regress performance compared to OOUI" as Krinkle says
[22:49:40] <EricGardner>	 I guess part of it depends on how long it will take to get a build step in place. If it's 1+ years, we may need something in the interim to guide folks
[22:49:51] <RoanKattouw>	 At least in terms of script execution time that wasn't the case for the example that I tested (which was a pathological case though)
[22:50:12] <Krinkle>	 My expectation is that in terms of bundle size, OOUI is much lower level for a given component than Vue + compiler + component file. so that'll be smaller.
[22:50:13] <RoanKattouw>	 In terms of bandwidth cost it could be
[22:50:45] <KateChapman>	 thanks everyone for the productive discussion. Any last minute questions before we wrap up before the end of the hour? Especially related to the current scope of the RFC?
[22:51:05] <EricGardner>	 do we need to "vote" on anything here? is that how this usually works?
[22:52:03] <KateChapman>	 no it is more input that TechCom will consider to put the RFC on last call and then approve it
[22:52:47] <milimetric>	 it feels like a lot of the folks active on the RFC phab task weren’t here, makes it harder to move forward
[22:53:36] <KateChapman>	 milimetric: I think the scope is we want to continue our experimentation and work with Vue. Comments such as "why not React" would really have to show why our current implementation path won't work at all
[22:53:51] <KateChapman>	 do you think there are people with concerns that we aren't addressing that are different than that?
[22:55:10] <EricGardner>	 I think the other main concern was around performance
[22:55:22] <milimetric>	 no, but I may be biased in ways that’s missing their point(s).  I would be ok with moving to last call, and seeing what the feedback on the task looks like after that
[22:55:36] <niedzielski>	 I agree with KateChapman. I think there are lots of details remaining to be explored but those will come with experimentation which is a part of FAWG's plan. I'm really excited to see those explorations continue.
[22:56:08] <KateChapman>	 EricGardner: without server side rendering or for other reasons?
[22:57:00] <milimetric>	 I think the other main point raised was Tim’s concern that developing extensions in multiple repos would be more cumbersome, but again that really depends on the build step discussion and is a bit out of scope for this phase
[22:57:16] <EricGardner>	 I think there are always perf concerns when we talk about introducing more JS into our ecosystem. The lack of server-rendering introduces a few additional concerns (shipping the compiler, etc) but personally I don't think those are very serious.
[22:58:09] <EricGardner>	 The other thing is that we'll need to try to port over important bits of OOUI (esp. concerning accessibility) – the more we utilize JS in our UI, the more of this work we need to do manually. But these aren't reasons to not move forward in my mind
[22:59:25] <KateChapman>	 okay so we are going to need to wrap up. I think we have enough info to discuss last call at the next TechCom meeting and as milimetric mentioned see what other discussion happens before approving
[23:01:17] <KateChapman>	 thanks for the discussion everyone
[23:01:26] <KateChapman>	 #endmeeting
[23:01:26] <wm-labs-meetbot>	 Meeting ended Wed Feb 19 23:01:26 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
[23:01:26] <wm-labs-meetbot>	 Minutes:        https://tools.wmflabs.org/meetbot/wikimedia-office/2020/wikimedia-office.2020-02-19-22.03.html
[23:01:26] <wm-labs-meetbot>	 Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2020/wikimedia-office.2020-02-19-22.03.txt
[23:01:26] <wm-labs-meetbot>	 Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2020/wikimedia-office.2020-02-19-22.03.wiki
[23:01:26] <wm-labs-meetbot>	 Log:            https://tools.wmflabs.org/meetbot/wikimedia-office/2020/wikimedia-office.2020-02-19-22.03.log.html