As you may recall from the last IRC meeting, I'm working on testing and documentation around issue #6137 [0] by removing some features/plugins/libraries and testing/documenting my success.
So far I've had good luck with removing some things (for instance tcpdf), but I've discovered two noteworthy problems.
1) When js/jqplot/ is removed, "Status -> Query statistics" does not fail gracefully, it instead offers to submit a report to the error reporting server.
2) when libraries/gis/ is removed, "Visulize GIS data" does not fail gravefully, instead it gets stuck on saying "Loading..."
In comparison, something that degrades very well is the removal of tcpdf; if the pdf library is missing the export dialog simply doesn't show PDF as an export type.
So my question is what you think we should do about this -- this is clearly beyond the scope of what is normally expected; it's not normal for a user to remove libraries and code, but in order for this feature request to be improved I think the code should handle this better. Should we spend time on this?
On 18 October 2015 at 19:56, Isaac Bennetch bennetch@gmail.com wrote:
As you may recall from the last IRC meeting, I'm working on testing and documentation around issue #6137 [0] by removing some features/plugins/libraries and testing/documenting my success.
So far I've had good luck with removing some things (for instance tcpdf), but I've discovered two noteworthy problems.
- When js/jqplot/ is removed, "Status -> Query statistics" does not
fail gracefully, it instead offers to submit a report to the error reporting server.
Additionally, query profiling, zoom search, display chart etc. should also
throw error.
- when libraries/gis/ is removed, "Visulize GIS data" does not fail
gravefully, instead it gets stuck on saying "Loading..."
In comparison, something that degrades very well is the removal of tcpdf; if the pdf library is missing the export dialog simply doesn't show PDF as an export type.
So my question is what you think we should do about this -- this is clearly beyond the scope of what is normally expected; it's not normal for a user to remove libraries and code, but in order for this feature request to be improved I think the code should handle this better. Should we spend time on this?
I also think that we should reconsider formally guiding/encouraging users
to manually remove files. Even if we go on to change code at various places - such that things exit gracefully on code removals - it seems less than a formal solution, which ought to be a plugin system to make less used features detachable/reloadable; until then we can leave this issue unresolved.
Le 2015-10-18 10:26, Isaac Bennetch a écrit :
As you may recall from the last IRC meeting, I'm working on testing and documentation around issue #6137 [0] by removing some features/plugins/libraries and testing/documenting my success.
So far I've had good luck with removing some things (for instance tcpdf), but I've discovered two noteworthy problems.
- When js/jqplot/ is removed, "Status -> Query statistics" does not
fail gracefully, it instead offers to submit a report to the error reporting server.
- when libraries/gis/ is removed, "Visulize GIS data" does not fail
gravefully, instead it gets stuck on saying "Loading..."
In comparison, something that degrades very well is the removal of tcpdf; if the pdf library is missing the export dialog simply doesn't show PDF as an export type.
So my question is what you think we should do about this -- this is clearly beyond the scope of what is normally expected; it's not normal for a user to remove libraries and code, but in order for this feature request to be improved I think the code should handle this better. Should we spend time on this?
I believe that for now, you should document how to remove only stuff that degrades well and close this issue.
On 10/19/15 7:07 AM, Marc Delisle wrote:
Le 2015-10-18 10:26, Isaac Bennetch a écrit :
As you may recall from the last IRC meeting, I'm working on testing and documentation around issue #6137 [0] by removing some features/plugins/libraries and testing/documenting my success.
So far I've had good luck with removing some things (for instance tcpdf), but I've discovered two noteworthy problems.
- When js/jqplot/ is removed, "Status -> Query statistics" does not
fail gracefully, it instead offers to submit a report to the error reporting server.
- when libraries/gis/ is removed, "Visulize GIS data" does not fail
gravefully, instead it gets stuck on saying "Loading..."
In comparison, something that degrades very well is the removal of tcpdf; if the pdf library is missing the export dialog simply doesn't show PDF as an export type.
So my question is what you think we should do about this -- this is clearly beyond the scope of what is normally expected; it's not normal for a user to remove libraries and code, but in order for this feature request to be improved I think the code should handle this better. Should we spend time on this?
I believe that for now, you should document how to remove only stuff that degrades well and close this issue.
Okay, I'll work toward that goal. Thanks.
On Mon, Oct 19, 2015 at 10:07 PM, Marc Delisle marc@infomarc.info wrote:
Le 2015-10-18 10:26, Isaac Bennetch a écrit :
As you may recall from the last IRC meeting, I'm working on testing and documentation around issue #6137 [0] by removing some features/plugins/libraries and testing/documenting my success.
So far I've had good luck with removing some things (for instance tcpdf), but I've discovered two noteworthy problems.
- When js/jqplot/ is removed, "Status -> Query statistics" does not
fail gracefully, it instead offers to submit a report to the error reporting server.
- when libraries/gis/ is removed, "Visulize GIS data" does not fail
gravefully, instead it gets stuck on saying "Loading..."
In comparison, something that degrades very well is the removal of tcpdf; if the pdf library is missing the export dialog simply doesn't show PDF as an export type.
So my question is what you think we should do about this -- this is clearly beyond the scope of what is normally expected; it's not normal for a user to remove libraries and code, but in order for this feature request to be improved I think the code should handle this better. Should we spend time on this?
I believe that for now, you should document how to remove only stuff that degrades well and close this issue.
And may be open issues for others to track the progress of them achieving
this status.
Hi
Dne Sun, 18 Oct 2015 10:26:07 -0400 Isaac Bennetch bennetch@gmail.com napsal(a):
As you may recall from the last IRC meeting, I'm working on testing and documentation around issue #6137 [0] by removing some features/plugins/libraries and testing/documenting my success.
So far I've had good luck with removing some things (for instance tcpdf), but I've discovered two noteworthy problems.
- When js/jqplot/ is removed, "Status -> Query statistics" does not
fail gracefully, it instead offers to submit a report to the error reporting server.
- when libraries/gis/ is removed, "Visulize GIS data" does not fail
gravefully, instead it gets stuck on saying "Loading..."
In comparison, something that degrades very well is the removal of tcpdf; if the pdf library is missing the export dialog simply doesn't show PDF as an export type.
For the PDF I've implemented it to allow optional dependency on TCPDF on Debian (full TCPDF is quite big pulling in several fonts as well in total bringing 13 MB), see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739521
So my question is what you think we should do about this -- this is clearly beyond the scope of what is normally expected; it's not normal for a user to remove libraries and code, but in order for this feature request to be improved I think the code should handle this better. Should we spend time on this?
I think we should document what is currently safe to remove (at least TCPDF, javascript sources, setup and translations are safe). I don't think it's worth to implement it for tiny libs (eg. GIS stuff has 160 KB).
On Wed, Oct 21, 2015 at 11:17 PM, Michal Čihař michal@cihar.com wrote:
Hi
Dne Sun, 18 Oct 2015 10:26:07 -0400 Isaac Bennetch bennetch@gmail.com napsal(a):
As you may recall from the last IRC meeting, I'm working on testing and documentation around issue #6137 [0] by removing some features/plugins/libraries and testing/documenting my success.
So far I've had good luck with removing some things (for instance tcpdf), but I've discovered two noteworthy problems.
- When js/jqplot/ is removed, "Status -> Query statistics" does not
fail gracefully, it instead offers to submit a report to the error reporting server.
- when libraries/gis/ is removed, "Visulize GIS data" does not fail
gravefully, instead it gets stuck on saying "Loading..."
In comparison, something that degrades very well is the removal of tcpdf; if the pdf library is missing the export dialog simply doesn't show PDF as an export type.
For the PDF I've implemented it to allow optional dependency on TCPDF on Debian (full TCPDF is quite big pulling in several fonts as well in total bringing 13 MB), see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739521
So my question is what you think we should do about this -- this is clearly beyond the scope of what is normally expected; it's not normal for a user to remove libraries and code, but in order for this feature request to be improved I think the code should handle this better. Should we spend time on this?
I think we should document what is currently safe to remove (at least TCPDF, javascript sources, setup and translations are safe). I don't think it's worth to implement it for tiny libs (eg. GIS stuff has 160 KB).
However, the JS part (OpenLayers library) is couple of Megabytes. I've
changes the code to function without it if removed.
-
Atul Pratap Singh -
Isaac Bennetch -
Madhura Jayaratne -
Marc Delisle -
Michal Čihař