EDEV: Quick Confirmation

A suggestion to reduce E2 load

[EDEV: Quick Confirmation|full node

What proportion of pages served are simply refreshed versions of the page the user is currently viewing?

E2 refreshes the screen in a number of cases:

• When a /msg is sent, or when a message is sent to the chatterbox
• When a C! is awarded
• When a vote is awarded
• Any other time the user doesn't specifically request a different node, but wishes to send data to the server.

However, the existing system that just returns a 1 has a few failings:

• It is not userfriendly
• It cannot be used easily as it isn't programmed in as a possible choice.

I propose changing this system to an system where it's value is the output to the browser, so that adding a &quicksys=Thank you for your vote! will suppress the refresh and display the message which requires far fewer system resources.

This would be best set up as a User Preference.

Apparently, this confirmation could be opened in a new window with <form target=_blank>, allowing the pop-up window to be closed quickly... thanks kaatunut!

---

The basic idea is that by presenting the user with a small page (ie: less than 1k) instead of a full node (can be huge) with no additional E2 backend work (no need to load up a node, nodelets etc) we can reduce server load and therefore E2 lag. By allowing the user to set up an option which doesn't advise him of the reputation of the writeups he voted on, doesn't reload the node just to advise him his message has been successfully sent (he'll see when he visits his next node), etc, etc.. hopefully E2 lag should decrease.

So the option in user preferences toggles between the current system (see votes, refresh screen) and the new (open pop-up window, display a small amount of text ('Thank you for your votes' or 'Your message has been sent' or whatever).

---

It's not so much queued as just not recieving the full node as confirmation. Admittedly, it's nice to see the votes you've sent. But if you have just C!hung someone, then do you really need to see the node again, just with a C!?

No Javascript would be required: if you want to C!, upvote and send a message, then three opcodes will be sent as three different requests. It's just that three less nodes are dragged up from the database. Opening in a new window isn't hard, either.

And I think most of the code already exists. I can't remember the parameter, but bunging something like &nodata=1 on the end just returns a '1'. Does anyone remember the name?

E2 is a dumb client of itself for all apparent purposes. If you think of the Everything Engine as a server application, with the data it holds for the user and all of the like, and the browser as the client, we are really dumb about the data transfer. We give everything to the client in one chunk, no matter if they interact with a node, the chatterbox, a superdoc, etc. All the data at one time is in "scope", even though the user doesn't care about all of it.

What The_Cow is suggesting (from what I'm reading) is to make E2 less "responsive" to the users. This would be a bad decision in general for a few reasons; the utmost of which would be the look and feel of the place would change. It wouldn't be a place where you enter a writeup, or vote, and then get the feedback from it right away... It would get queued up and then reduced to being as exciting as one's interactions with an office printer. The site would be less "fun".

Other than that, there are other ramifications:

• The code changes would be huge. There would be a lot of JavaScript involved, making the site less [compatible. Right now we don't rely on JS to do anything (but use it for a few perks). E2 doesn't currently pop up new windows, and I really like that about it. I really want it to stay that way.
• The opcode queuing would change the way it all works. Right now the engine works kinda like (from my understanding...) one opcode == one result. You put something in, you get back the results of your operation. Stacking them up is something the server doesn't support.
• You probably aren't shaving off that many cycles for the huge code hit you are talking about. To me, the amount needed to put in doesn't equal the amount gotten in return.

You have however, identified a few problems here that others have seen. There are a few ways, that I can see that would allow you to make an impact on this sort of thing:

• An I-Framed (I-Layered chatterbox). The chatterbox may be something that would be a great candidate for an IFRAME (under IE), or an ILAYER (under Netscape). Something that is able to be refreshed without having to redo the entire page. This would shave cycles from chatterbox users who are only getting the results back. This would fall under the category of quick confirmation for the pages, but only for the catbox. The entire site wouldn't work well as frames (I, for one, would snap), but an IFRAME / ILAYER solution may work just fine, without being instrusive.
• More items that intelligently use the XML Ticker, similar to N-Wing's Java Chatterbox. How many people actually use something that minimizes the strain put on the the server by actually using a Ticker product or what not? These things can cut valuable cycles off of the server if used properly... It's not a browser solution, but it is a solution.

Changing the way E2 works for such a small gain wouldn't be worth the hassle of doing this, even if it were simply a user preference. Admittedly, I wouldn't want to use it, and I don't know how many other people would, under your current description.