Some remarks:
- Junk the chatterbox
- I disagree with that. I think the integration with the site is essential and has significant advantages above IRC by itself. However, what I don't understand is why the ChatterBox is not in an Iframe, so it could be refreshed by itself. Surely most browsers nowadays support this?
- Cancel SuperSearch
- I hope to be able to come up with a solution for that before too long.
Also with regards to voting: each time a vote is done, the whole page needs to be regenerated. Even though I'm not that interested in knowing the result. And double voting is already handled (i.e. ignored) by the system.
So why not have an option in your user settings that, if set, would return a status 204 (no change) on a vote? The page would remain on screen for you to continue to read and/or go to a next node. And the page would not have to be regenerated. In my average morning run through the monastery, that would save about half of the pages from having to be generated.
Liz | [reply] |
Both of those are exelecent ideas, and I'd look into implementing the first, which shouldn't be all that difficult to do, preferably as an option. (Many people are using iframeless browsers, or have iframes disabled or filtered.) It should help decently much.
The second option would be wonderful, but probably quite difficult to implement -- I don't know of any existing mechinisim to change the HTTP-level response code of everything-generated pages, but it would be quite useful indeed. (However, it may well be implementable, esp since I think (but am not certian...) that everything is rendered, then sent to the browser in one go.)
I'd look into the big question of the second, but I'm rather full of things on my PM-related hacking TODO list -- replyable patches at present. Since, IIRC, you aren't a pmdev, /msg'ing gods is the first step. Then, a week later, start looking at the code -- for the first, at the chatterbox nodelet, for the second Everything/HTML.pm, and the function Everything::HTML::displayPage, and in purticular, exporting something with which nodes can directly effect the arguments to printHeader. (If, at the same time, you create some way to allow for explicit flushes, such that the header and some of the content get output to the client before rendering is actualy complete, you could signifiantly speed up the /precived/ speed of perlmonks (but not the actual speed). The later will be quite difficult, I think, but the former significantly less so -- though my suggested implementation would add another global.
Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).
| [reply] |
...using iframeless browsers, or have iframes disabled...
The banner runs in an iframe (if it runs).
...that everything is rendered, then sent to the browser in one go...
But you want to prevent it being rendered, as that is (presumably) the big load on the database server (please note that I have not had a look at any of the everything code: mainly to protect myself ;-) You want it to just handle the votes and then just send a 204 status without rendering or sending anything else.
Liz
| [reply] |
Junk the chatterbox. If people want to chat they know where IRC is. I can't use IRC at work. Chatterbox has kept me sane for the last 2 weeks.
| [reply] |
Killing the CB: Add another vote for keeping the chatterbox.
IRC isn't ways available (i.e. because it's being blocked by the corporate firewall), but web traffic is OK.
Getting quick help and taking a break in the CB is really helpful and aids in maintaining a sane outlook on the World :-)
Offlining the past: IMHO, if a node has a certain amount of views or rep, regardless of it's age, it might be worthwhile keeping, rather than placing in cold storage.
If the information in this post is inaccurate, or just plain wrong, don't just downvote - please post explaining what's wrong.
That way everyone learns.
| [reply] |
And while you are at it, cancel the AnonyMonks as well. I guess they cause a higer workload than the monks romping around the monastery. | [reply] |
| [reply] |