docs/Makefile.am | 4 +--- docs/index.html.in | 6 +++--- docs/js/jquery-3.1.1.min.js | 4 ---- docs/js/jquery.rss.min.js | 11 ----------- docs/js/moment.min.js | 7 ------- 5 files changed, 4 insertions(+), 28 deletions(-) delete mode 100644 docs/js/jquery-3.1.1.min.js delete mode 100644 docs/js/jquery.rss.min.js delete mode 100644 docs/js/moment.min.js
We're carrying around embedded copies of a few JavaScript libraries for use in our homepage, and we've been unforgivably bad at keeping them up to date. Instead of serving JavaScript from libvirt.org, use CDNJS so that users will get better performance and the load on our Web server will decrease (win-win!); at the same time, move from the positively ancient versions we're currently using to the freshest ones available. Andrea Bolognani (4): docs: Use CDNJS for Moment.js docs: Use CDNJS for jquery.rss docs: Use CDNJS for jQuery docs: Update JavaScript libraries docs/Makefile.am | 4 +--- docs/index.html.in | 6 +++--- docs/js/jquery-3.1.1.min.js | 4 ---- docs/js/jquery.rss.min.js | 11 ----------- docs/js/moment.min.js | 7 ------- 5 files changed, 4 insertions(+), 28 deletions(-) delete mode 100644 docs/js/jquery-3.1.1.min.js delete mode 100644 docs/js/jquery.rss.min.js delete mode 100644 docs/js/moment.min.js -- 2.21.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Jun 18, 2019 at 10:12:39AM +0200, Andrea Bolognani wrote: > We're carrying around embedded copies of a few JavaScript libraries > for use in our homepage, and we've been unforgivably bad at keeping > them up to date. > > Instead of serving JavaScript from libvirt.org, use CDNJS so that > users will get better performance and the load on our Web server > will decrease (win-win!); at the same time, move from the positively > ancient versions we're currently using to the freshest ones > available. I'm in favour of updating the code of course, but I'd like to keep it self-contained on our own site, certainly not support cloudflare. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Jun 18, 2019 at 09:48:42AM +0100, Daniel P. Berrangé wrote: >On Tue, Jun 18, 2019 at 10:12:39AM +0200, Andrea Bolognani wrote: >> We're carrying around embedded copies of a few JavaScript libraries >> for use in our homepage, and we've been unforgivably bad at keeping >> them up to date. >> >> Instead of serving JavaScript from libvirt.org, use CDNJS so that >> users will get better performance and the load on our Web server >> will decrease (win-win!); at the same time, move from the positively >> ancient versions we're currently using to the freshest ones >> available. > >I'm in favour of updating the code of course, but I'd like to keep it >self-contained on our own site, certainly not support cloudflare. > Especially if we still have to manually update it, which I thought this patch is helping with =) >Regards, >Daniel >-- >|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| >|: https://libvirt.org -o- https://fstop138.berrange.com :| >|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| > >-- >libvir-list mailing list >libvir-list@redhat.com >https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, 2019-06-18 at 09:48 +0100, Daniel P. Berrangé wrote: > On Tue, Jun 18, 2019 at 10:12:39AM +0200, Andrea Bolognani wrote: > > We're carrying around embedded copies of a few JavaScript libraries > > for use in our homepage, and we've been unforgivably bad at keeping > > them up to date. > > > > Instead of serving JavaScript from libvirt.org, use CDNJS so that > > users will get better performance and the load on our Web server > > will decrease (win-win!); at the same time, move from the positively > > ancient versions we're currently using to the freshest ones > > available. > > I'm in favour of updating the code of course, but I'd like to keep it > self-contained on our own site, certainly not support cloudflare. Why? CDNJS is a completely open source project that just so happens to be hosted on, and sponsored by, CloudFlare. Including minimized JavaScript files in release archives as we're doing right now is also pretty sketchy, since it's basically the same as shipping pre-built binaries instead of the corresponding sources. Debian has a fairly strict policy against it, which is how I came to realized it was an issue in the first place, but I'd be surprised if other distributions were happy with the situation. We're only using JavaScript for the fancy blog roll on the homepage and global search drop-down menu anyway, both of which are only relevant to libvirt.org and should be scrapped when installing documentation on the end user's machine. I'm working on a follow-up series that does just that. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Jun 18, 2019 at 11:19:20AM +0200, Andrea Bolognani wrote: > On Tue, 2019-06-18 at 09:48 +0100, Daniel P. Berrangé wrote: > > On Tue, Jun 18, 2019 at 10:12:39AM +0200, Andrea Bolognani wrote: > > > We're carrying around embedded copies of a few JavaScript libraries > > > for use in our homepage, and we've been unforgivably bad at keeping > > > them up to date. > > > > > > Instead of serving JavaScript from libvirt.org, use CDNJS so that > > > users will get better performance and the load on our Web server > > > will decrease (win-win!); at the same time, move from the positively > > > ancient versions we're currently using to the freshest ones > > > available. > > > > I'm in favour of updating the code of course, but I'd like to keep it > > self-contained on our own site, certainly not support cloudflare. > > Why? CDNJS is a completely open source project that just so happens > to be hosted on, and sponsored by, CloudFlare. I don't see us having any real problem with self-hosting the content we have done since this was first added. There's not much of it, our site is not a high traffic site, and we've got many much larger files hosted. > Including minimized JavaScript files in release archives as we're > doing right now is also pretty sketchy, since it's basically the same > as shipping pre-built binaries instead of the corresponding sources. > Debian has a fairly strict policy against it, which is how I came to > realized it was an issue in the first place, but I'd be surprised if > other distributions were happy with the situation. I'm fine if we put non-minimized JS in GIT & (optionally) minimize it during build. > We're only using JavaScript for the fancy blog roll on the homepage > and global search drop-down menu anyway, both of which are only > relevant to libvirt.org and should be scrapped when installing > documentation on the end user's machine. I'm working on a follow-up > series that does just that. Is there really a benefit to disabling it locally ? IMHO it is fine to have it locally, not least as it lets people changing the website see it in the same way it will look when published live. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, 2019-06-18 at 10:39 +0100, Daniel P. Berrangé wrote: > On Tue, Jun 18, 2019 at 11:19:20AM +0200, Andrea Bolognani wrote: > > Including minimized JavaScript files in release archives as we're > > doing right now is also pretty sketchy, since it's basically the same > > as shipping pre-built binaries instead of the corresponding sources. > > Debian has a fairly strict policy against it, which is how I came to > > realized it was an issue in the first place, but I'd be surprised if > > other distributions were happy with the situation. > > I'm fine if we put non-minimized JS in GIT & (optionally) minimize it > during build. That would be an improvement on the current situation, but it would also mean hooking up a JavaScript minifier to our build system. I'm not quite sure how those things work, but I think the ones that are widely used depend on node.js and who knows how many nano-libraries pulled from NPM to do their thing? Counter-proposal: can we just get rid of the RSS widget from the homepage? That's literally the only reason we included all this JavaScript in the first place. It's cute, but possibly not worth the effort if you take into account having to spend time keeping up with updates to jQuery and friends, which if history is any indication we'd do a pretty awful job at anyway. As a data point, the QEMU website provides a link to Planet Virt Tools in its footer. We could do the same: we even already have a bunch of links there. > > We're only using JavaScript for the fancy blog roll on the homepage > > and global search drop-down menu anyway, both of which are only > > relevant to libvirt.org and should be scrapped when installing > > documentation on the end user's machine. I'm working on a follow-up > > series that does just that. > > Is there really a benefit to disabling it locally ? IMHO it is fine to > have it locally, not least as it lets people changing the website see > it in the same way it will look when published live. Ideally browsing locally installed documentation would not result in poking around the Internet. Even when the lack of network connection is handled gracefully, which is the case for us already, it can be considered a minor breach of privacy to load online resources when the user's expectations are to be only accessing local content. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Jun 18, 2019 at 12:15:46PM +0200, Andrea Bolognani wrote: > On Tue, 2019-06-18 at 10:39 +0100, Daniel P. Berrangé wrote: > > On Tue, Jun 18, 2019 at 11:19:20AM +0200, Andrea Bolognani wrote: > > > Including minimized JavaScript files in release archives as we're > > > doing right now is also pretty sketchy, since it's basically the same > > > as shipping pre-built binaries instead of the corresponding sources. > > > Debian has a fairly strict policy against it, which is how I came to > > > realized it was an issue in the first place, but I'd be surprised if > > > other distributions were happy with the situation. > > > > I'm fine if we put non-minimized JS in GIT & (optionally) minimize it > > during build. > > That would be an improvement on the current situation, but it would > also mean hooking up a JavaScript minifier to our build system. I'm > not quite sure how those things work, but I think the ones that are > widely used depend on node.js and who knows how many nano-libraries > pulled from NPM to do their thing? Fedora has uglify-js RPM present in its repos which is trivial to install & use $ uglify-js foo.js > foo.min.js If a distro lacks this package, simply don't minimize it. > Counter-proposal: can we just get rid of the RSS widget from the > homepage? That's literally the only reason we included all this > JavaScript in the first place. It's cute, but possibly not worth > the effort if you take into account having to spend time keeping up > with updates to jQuery and friends, which if history is any > indication we'd do a pretty awful job at anyway. > > As a data point, the QEMU website provides a link to Planet Virt > Tools in its footer. We could do the same: we even already have a > bunch of links there. Hiding a link in the footer is really poor in comparison. The point of having the feed content on the website is that it gives direct visibility to visitors of the site. Far fewer will notice & follow a link in the footer. We need to be improving visibility of relevant content, not making it worse. Updating jQuery is not a burden / timesink. It is something we haven't considered a priority to bother with as it has just worked fine. So there's no compelling reason to remove it when it is serving an important use case. > > > We're only using JavaScript for the fancy blog roll on the homepage > > > and global search drop-down menu anyway, both of which are only > > > relevant to libvirt.org and should be scrapped when installing > > > documentation on the end user's machine. I'm working on a follow-up > > > series that does just that. > > > > Is there really a benefit to disabling it locally ? IMHO it is fine to > > have it locally, not least as it lets people changing the website see > > it in the same way it will look when published live. > > Ideally browsing locally installed documentation would not result > in poking around the Internet. Even when the lack of network > connection is handled gracefully, which is the case for us already, > it can be considered a minor breach of privacy to load online > resources when the user's expectations are to be only accessing > local content. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, 2019-06-18 at 11:53 +0100, Daniel P. Berrangé wrote: > On Tue, Jun 18, 2019 at 12:15:46PM +0200, Andrea Bolognani wrote: > > That would be an improvement on the current situation, but it would > > also mean hooking up a JavaScript minifier to our build system. I'm > > not quite sure how those things work, but I think the ones that are > > widely used depend on node.js and who knows how many nano-libraries > > pulled from NPM to do their thing? > > Fedora has uglify-js RPM present in its repos which is trivial > to install & use > > $ uglify-js foo.js > foo.min.js > > If a distro lacks this package, simply don't minimize it. Alright, I'll admit that's not as bad as I feared :) > > Counter-proposal: can we just get rid of the RSS widget from the > > homepage? That's literally the only reason we included all this > > JavaScript in the first place. It's cute, but possibly not worth > > the effort if you take into account having to spend time keeping up > > with updates to jQuery and friends, which if history is any > > indication we'd do a pretty awful job at anyway. > > > > As a data point, the QEMU website provides a link to Planet Virt > > Tools in its footer. We could do the same: we even already have a > > bunch of links there. > > Hiding a link in the footer is really poor in comparison. The point > of having the feed content on the website is that it gives direct > visibility to visitors of the site. Far fewer will notice & follow > a link in the footer. We need to be improving visibility of relevant > content, not making it worse. > > Updating jQuery is not a burden / timesink. It is something we > haven't considered a priority to bother with as it has just worked > fine. So there's no compelling reason to remove it when it is > serving an important use case. I'm okay with having links to Planet Virt Tools very visible, but I disagree that the only way to achieve that is through a JavaScript powered blog roll. For example, we could keep the third column of the homepage and rename it to "Community", then move all the "Community" links from the footer to that column. Pretty visible still, and no JavaScript, Would you consider that acceptable? -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Jun 18, 2019 at 02:23:28PM +0200, Andrea Bolognani wrote: > On Tue, 2019-06-18 at 11:53 +0100, Daniel P. Berrangé wrote: > > On Tue, Jun 18, 2019 at 12:15:46PM +0200, Andrea Bolognani wrote: > > > That would be an improvement on the current situation, but it would > > > also mean hooking up a JavaScript minifier to our build system. I'm > > > not quite sure how those things work, but I think the ones that are > > > widely used depend on node.js and who knows how many nano-libraries > > > pulled from NPM to do their thing? > > > > Fedora has uglify-js RPM present in its repos which is trivial > > to install & use > > > > $ uglify-js foo.js > foo.min.js > > > > If a distro lacks this package, simply don't minimize it. > > Alright, I'll admit that's not as bad as I feared :) > > > > Counter-proposal: can we just get rid of the RSS widget from the > > > homepage? That's literally the only reason we included all this > > > JavaScript in the first place. It's cute, but possibly not worth > > > the effort if you take into account having to spend time keeping up > > > with updates to jQuery and friends, which if history is any > > > indication we'd do a pretty awful job at anyway. > > > > > > As a data point, the QEMU website provides a link to Planet Virt > > > Tools in its footer. We could do the same: we even already have a > > > bunch of links there. > > > > Hiding a link in the footer is really poor in comparison. The point > > of having the feed content on the website is that it gives direct > > visibility to visitors of the site. Far fewer will notice & follow > > a link in the footer. We need to be improving visibility of relevant > > content, not making it worse. > > > > Updating jQuery is not a burden / timesink. It is something we > > haven't considered a priority to bother with as it has just worked > > fine. So there's no compelling reason to remove it when it is > > serving an important use case. > > I'm okay with having links to Planet Virt Tools very visible, but I > disagree that the only way to achieve that is through a JavaScript > powered blog roll. > > For example, we could keep the third column of the homepage and > rename it to "Community", then move all the "Community" links from > the footer to that column. Pretty visible still, and no JavaScript, > > Would you consider that acceptable? Well its better than everything in the footer, but I still believe it is significantly worse than what we have already. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Jun 18, 2019 at 10:39:40 +0100, Daniel Berrange wrote: > On Tue, Jun 18, 2019 at 11:19:20AM +0200, Andrea Bolognani wrote: > > On Tue, 2019-06-18 at 09:48 +0100, Daniel P. Berrangé wrote: > > > On Tue, Jun 18, 2019 at 10:12:39AM +0200, Andrea Bolognani wrote: > > > > We're carrying around embedded copies of a few JavaScript libraries > > > > for use in our homepage, and we've been unforgivably bad at keeping > > > > them up to date. > > > > > > > > Instead of serving JavaScript from libvirt.org, use CDNJS so that > > > > users will get better performance and the load on our Web server > > > > will decrease (win-win!); at the same time, move from the positively > > > > ancient versions we're currently using to the freshest ones > > > > available. > > > > > > I'm in favour of updating the code of course, but I'd like to keep it > > > self-contained on our own site, certainly not support cloudflare. > > > > Why? CDNJS is a completely open source project that just so happens > > to be hosted on, and sponsored by, CloudFlare. > > I don't see us having any real problem with self-hosting the content > we have done since this was first added. There's not much of it, our > site is not a high traffic site, and we've got many much larger files > hosted. > > > Including minimized JavaScript files in release archives as we're > > doing right now is also pretty sketchy, since it's basically the same > > as shipping pre-built binaries instead of the corresponding sources. > > Debian has a fairly strict policy against it, which is how I came to > > realized it was an issue in the first place, but I'd be surprised if > > other distributions were happy with the situation. > > I'm fine if we put non-minimized JS in GIT & (optionally) minimize it > during build. But what's the point of having it in git of libvirt? I can understand that we generate the docs from there. But we don't really need JS for the docs. The main page and everything is by itself pretty weird to be in libvirt.git -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, 2019-06-18 at 12:18 +0200, Peter Krempa wrote: > On Tue, Jun 18, 2019 at 10:39:40 +0100, Daniel Berrange wrote: > But what's the point of having it in git of libvirt? I can understand > that we generate the docs from there. But we don't really need JS for > the docs. > > The main page and everything is by itself pretty weird to be in > libvirt.git That's kind of true, and has been slightly bothering me for a long time now; however if you look at the website it's like 99% user and developer documentation that we want to ship and ultimately install as part of releases, with index.html and 404.html being the only exceptions I can point out off the top of my head. There might be a few more, but their size pales in comparison with the rest. Splitting off those few pages to a separate repository would mean having to duplicate a lot of effort (build system, etc.) for very little gain at the end of the day, so I don't think it's something that we should pursue. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Tue, Jun 18, 2019 at 12:24:48 +0200, Andrea Bolognani wrote: > On Tue, 2019-06-18 at 12:18 +0200, Peter Krempa wrote: > > On Tue, Jun 18, 2019 at 10:39:40 +0100, Daniel Berrange wrote: > > But what's the point of having it in git of libvirt? I can understand > > that we generate the docs from there. But we don't really need JS for > > the docs. > > > > The main page and everything is by itself pretty weird to be in > > libvirt.git > > That's kind of true, and has been slightly bothering me for a long > time now; however if you look at the website it's like 99% user and > developer documentation that we want to ship and ultimately install > as part of releases, with index.html and 404.html being the only > exceptions I can point out off the top of my head. There might be > a few more, but their size pales in comparison with the rest. > Splitting off those few pages to a separate repository would mean > having to duplicate a lot of effort (build system, etc.) for very > little gain at the end of the day, so I don't think it's something > that we should pursue. I must say that I mostly care about the JS stuff being gone from the repo. I don't mind other things that much. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2024 Red Hat, Inc.