This is a request for comments:
The working concept of this is
located at:
http://www.manifestresearch.com/e2/jsmsg.htm
For right now, it is IE only. (read below for details). The code is freely viewable.
What is it?
It is a way to
message people without having to reload the page, backed heavily by
JavaScript. This means that we can ALWAYS
post the opcode data to a very
inexpensive page, rather than a possibly more
expensive one, like say
Message Inbox,
PoC, etc.
How does it work?
It works by a very
complicated series of scripts to
back-post into an
invisible frame the
contents of the
message, and then send it off to an
inexpensive page on the
server. It
manages the
user session by placing up a
fore-front yellow window to handle the dialogue, and contain the window.
Why is it IE only?
My
experience is in
IE mainly, and I have the IE documentation right in front of me. I made sure I used calls with parity to ones in the
NS object model, and I will
back port, if there is any
interest for this.
Why will it help E2?
It makes a smarter choice of message targets for E2. It will
reduce what we have to
generate to send
messages to the
system to the bare minimum (with a little help from the
server). Also, if I
spruced it up a little more, I think it makes for a neat UI element.
What works:
- User names with spaces in the name are properly escaped to using the underscore
- Link generation and window generation
- The sending of messages
- Link of the name to send to
- "confirmation message" (Read below)
- Gauranteed message "safety": The JS app puts the /msg whomever in the message dialog. This is fairly failsafe. No more .msg (person) crap.
Possible applications:
A message linktype. If a person clicks on a link of a certain type, it will then just call performPopup(namehere) and then the window should appear just fine. A link generator is included with the page. Type the name you want to generate the link for, and click on it to bring up the mini-window
- A similar/smarter js chatterbox client For people who casually chat in the 'box, I could mock up an off-frame js do-hickey, that works on similar concepts.
- A more js-enhanced, less reload-expensive message inbox-esque superdoc. So that we can be cheaper about sending piles of messages.
Outstanding bugs:
- Doesn't work in Netscape: That is on the way to being fixed.
- You need to be connected through www.everything2.com: Because we are offsite, and the cookies work kinda funny, you need to be connected through www.everything2.com... IE: You connection needs to look exactly like mine would for it to work right now. This bug will solve itself when we get moved over the the server. Thanks to atesh for finding this one.
- The script secretly uses the front page to post against, which is not an inexpensive page It seems that if you post information to e2 from an outside source, no matter what you give it in the GET data in IE, it still gives you the front page. For this reason, it seems that we won't be able to actually use a cheap page until I get it inside of an edevdoc or superdoc. Then we'll use the printable version of something cheap (as it takes seemingly little to generate one).
- You need to be logged in to perform this action: Because we are "outside" of e2 for the minute, messaging from off of e2 requires a cookie ahead of time. This will be solved when I move it to the server.
- You don't get true feedback as to when the message is sent: Because I don't cross-frame scrub the page to get the information, there is no real feedback, but I set a timer to tell you when the message should be in. *gulp*, which leads us to the real "feature":
- The communication is not 100% reliable: If you send the request off, chances are it will get sent. However, under lag conditions (which we never see here, of course), or in an Internet storm, your request could get lost, and you may never know. There is a drop dead time of four seconds, in which we then kill the communication, and say the message was sent. It's not the best mode of transport, but it should work, since e2 is receiving the data, and doing something with it, even if you aren't there to listen for the answer. (very very cheap, I think, if Apache does what I think it does).
Future features:
- A cheap and useful target: Ideally, I'd love for someone to code me a superdoc whose entire information contains the response text to a message (like that found in the bottom of the chatterbox, or in the message inbox after you send a message (pretty pretty please N-Wing, nate, or someone else). Then I could scrub that reply and maybe get information back for a confirmation.
- Better "window" placement: I need to be a little smarter about where the layer goes. That depends on what information NS is going to give me, and positining inside of e2.
- Jukka it up: Let's make it's colors play nice on the system maybe. This is a really low priority.
- Auto-link detection. *gulp* that one will be hard...
Other suggestions for message lag reduction:
- We could develop a multi-message MI that could batch together messages. It's almost the same thing, without the cool and neato interface thing.
That's a lot of junk
there, and I apologize for making it so
long and
scattered. Please, let me know your comments. Like I've said, if I get enough positive feedback, a
dual-IE and NS version will be forthcoming. I'll need
people who will want to test it as well. Thoughts, volunteers, and
detailed bug reports welcome.