Draft: new web interface

Could you please at least rebase this properly? I can see gratuitious reversions of changes that were made meanwhile in at least http.lua and httprequests.lua.

Also please do take into account the feedback that was already received when this was posted last year, at least mine speaking for myself:

NAK on the HTTPd core changes, which look inappropriate to me and should be the object of proper fixes in a separate merge request.

And I can't even fully browse this merge request to review it, as it attempts to take more than 1 GB of RAM in its Firefox tab. Please fix so I and others can review.

I guess, by the presence of the Draft: prefix, that J-B mainly put the branch back here so as to start tracking it. Thank you for linking the previous issues.

Exactly :)

It's far from finished, but it's there to not lose the work.

Could you please at least rebase this properly? I can see gratuitious reversions of changes that were made meanwhile in at least http.lua and httprequests.lua.

This should have been fixed.

https://mailman.videolan.org/pipermail/vlc-devel/2020-August/135811.html

This can wait for another MR to continue cleaning.

I guess, by the presence of the Draft: prefix, that J-B mainly put the branch back here so as to start tracking it. Thank you for linking the previous issues.

I checked and linked MY issues with the patchset. There were others and I don't know if they've been addressed in this version of the patchset. But you're right, we need to go back, check those other reviews and link and start tracking them here as well.

This should have been fixed.

The "Compare with previous version" link brings me to a diff page with the error "Something went wrong on our end. Please try again!" Trying again doesn't help. So I can't review.

This can wait for another MR to continue cleaning.

I'm not sure what exactly you mean by that. But I was the one who cleaned it up last time in the current version, so I'm opposed to merging anything that doesn't get it right the first time this time and would be a regression from my cleanup, and no this can't wait until a hypothetical later refinement - especially considering my current reviews still haven't been addressed in a year.

I suggest you start calming down your tone, if you don't want your reviews to be completely ignored.

There is no reasons for this aggressiveness on a Draft MR of this complexity, and this will not be tolerated.

I was not aggressive. I understand if you felt I was aggressive because I pointed out every way this patchset, your effort to port it here, or GitLab technicals, still fell short of expected standards; and yes I'm sorry if I upset you by stepping in to point these out, but you didn't when creating the MR and so it wasn't clear. This is frustrating for me too, so I can empathize.

However your remarks could feel to me like a threat aimed at silencing me. But I'm sure you didn't mean it that way. So let's deescalate in emotions. But I still stand on my objective technical points.

added 8 commits

352062b3...c56c3f3f - 8 commits from branch videolan:master

Compare with previous version

added 13 commits

dbe55b36 - http: add eslintrc.json
2327f3d0 - http: modern redesign
d6d57257 - httpd: Fix potential null-dereference in case of error
fc3699b6 - lua: Add a minimal medialib API
d05e6eaa - http: update .gitignore
a40d38cc - http: update dependencies
ac231ef8 - http: update assets
ad2d0c37 - http: add utils
e79ccbf1 - http: add store & services
5a52cdc8 - http: update common styles
4c1f5bc5 - http: add new routes & components
4bbe0814 - http(medialibrary): update according to 45289776
aecd75cd - http: minor UI adjustments

Compare with previous version

Can you please provide metrics for the accessibility and performance of this new interface, compared to the current one? We'd need to review those.

Accessibility should be reviewed, indeed, and a ticket should be created.

But since the scope of features of this new interface is way different, comparing for performance is going to be very difficult.

Accessibility should be reviewed, indeed, and a ticket should be created.

Okay, have you created one? Who's doing it?

But since the scope of features of this new interface is way different, comparing for performance is going to be very difficult.

Of course. There's a basic subset that isn't optional though, like landing on the home page, opening a file and playing it... I meant that at least that shouldn't result in clunky browser performance due to a new framework or whatever the reason, compared to current functionality that would be replaced.

Thanks, @linkfanel, for pointing these issues.
Sorry if I haven't respected all the standards, it's all my bad. I will improve this MR in my free times with the provide review. However, keep in mind that's a Draft and a huge improvement over the existent interface.

This is not perfect, I don't have the time to provide a 100% finalized product on first shot, sorry about that too.
The idea here is to initiate a modern redesign.
Then, we can iterate to start building a modern web app with all the Web standards and performance/accessibility metrics.

No, thanks to you for looking into this, but I should have also given you the full background. There's a ticket for this: #25020 We don't want the web interface to link to resources over the internet (such as js or images hosted online), for a bunch of reasons. But it can get complicated, for example if VLC's web interface self-hosts minified js files, then we need to bring into the build system everything needed to regenerate those minified files from source.

With the current version of the web interface, we made some mistakes and overlooked some other things - we'd like to learn from this. There were a bunch of easy fixes last year (https://code.videolan.org/videolan/vlc/-/commits/master/share/lua/http), but some things were too complicated or too late to fix in the stable version. So there was a consensus that the next interface would get this right. Now nobody's asking for a 100% perfect interface the first time, indeed :) However, for these reasons and because it affects security, privacy and legal requirements, that part is not something I think I can accept as a later refinement.

As for a modern redesign, well not everybody likes or enjoys a modern redesign just for the sake of it, although that's a question in itself. And in the case of GitLab, now it's also turning out to be painful, yet it's too late to fix or undo now. So if a new framework and design inherently entails heavy costs in performance, that seems like a pretty core concern to me, that we want to get at least a good idea about in the first drafts. Could you run some performance analysis using browser web development tools or something like that, and post comparative results for it?

Superseded by !745

closed

added MRStatus::Duplicate label

Draft: new web interface

Merge request reports

Activity