I think I might have 2c to clarify the OP's stand, having worked on a mobile XMPP client before. This is with regards to his point about bandwidth and battery usage on mobile.
XMPP is a connection-oriented stateful protocol. The connection setup process is very expensive: Connect, authenticate, advertise the list of supported client features, get the roster (contacts), and IIRC presence exchange, etc. Therefore, once you've established a connection, you really don't want it to break. Even just reconnecting is very expensive.
However, in the mobile scenario, regular connection breakage is the norm. What most mobile based clients will then do is proxy the XMPP connection on the server-side and connect to the client over HTTP instead. This is well defined in the BoSH spec (XEP:124). BoSH was originally designed for web-based clients, but happens to meet the need of the mobile use-case.
However, when it comes down to implementation, there are several optimizations that can be applied:
1. The roster exchange at the connection time is very expensive, and usually only sends data to the client that the client probably has already stored locally from a pervious session. Connection overhead can be reduced drastically if there was some way of versioning the roster and only transferring deltas. This was the OP was referring to. (Roster versioning, XEP:273).
2. Presence packets are one of the most chatty aspects of the protocol (x went offline, x is now online, etc). I've heard someone say that it constitutes about 80% of the packets on a typical connection, but this is anecdotal. In cases where the user isn't actively interacting with the client, having presence packets being sent all the time seems wasteful. One way to tackle this is to buffer up and de-duplicate the presence packets on the server, and send them in batches only when necessary. (For example, if x goes online, then offline, then online again, and then goes 'busy', the client only needs to know that x is busy.) I think this is what the OP was referring to when he mentioned the google:queue for delayed presence delivery. This alone can be a huge win for battery and bandwidth, since transferring data and processing it can be reduced drastically.
Aside: Presence is so chatty, that some mobile clients simply don't handle presence at all. Take WhatsApp for example. It doesn't show whether every person in your list of contacts is online. The assumption is that every user is online by the nature of the device, and this assumption works in the common cases. In the edge cases is where you'd need to buffer up messages. This reduces chattiness drastically, making the protocol seem much more lightweight. (WhatsApp is based on XMPP, but have spun it off into their own thing.)
Just thought I'd add these points to the discussion here, since there seemed to be some lack of understanding of the protocol. IMHO, the XML, as verbose as it is, isn't really the problem. The protocol itself is verbose and whether the transport uses XML or whatever else is of comparatively little consequence. This verbosity of the protocol (and not so much the format of data transfer) has its effect on battery life and bandwidth usage.
It isn't possible to have a single "wrapper" try/catch in JS, because of the event-loop nature of most JS hosts. This is because functions that are scheduled to run on the event loop (say, using a button click, or a ajax call), aren't in the same call-stack as the code that defined it. Since they aren't in the same call-stack, an outer try/catch won't work on the inner callback.
If it weren't for the fact that we don't get column numbers in window.error, I would have already supported source maps in http://errorception.com/ by now. I'm still looking actively for ways to include support though.
"Script Error" at line 0 only occurs in Firefox - I know, I'm in the business of collecting errors ;). It seems to happen when the JS file couldn't be parsed correctly. The cause for this usually partially downloaded files on the client trying to be passed through the interpreter.
Other than some little HTTP tweaks that can be done, there's very little else that you can do with "Script Error"s. So, we don't even bother sending "Script Error at line 0" errors to the server. For all practical purposes, it's a meaningless error.
You aren't wrong if you are looking at the server's resource consumption. However, the need to buffer the errors is so that we can minimize network overhead, from the client's perspective. It's to reduce the number of HTTP connections, even if it means the payload is larger - much like why CSS sprites are a good idea.
If this is happening in Firefox, it's usually because the JS file couldn't be parsed correctly. In my experience this is usually because of partial/interrupted download of the code.
I'm the developer of Errorception (http://errorception.com/), and wanted to jump in to talk about some of the points raised on the thread here.
As chrisacky mentioned, making one HTTP post for every error is very wasteful. It's much better to buffer up such errors (Errorception does it in memory, since localStorage can be unavailable and/or full), and post them every once in a while.
As masklinn pointed out, window.onerror _is_ complete shit, so Errorception does a couple of tricks to make this slightly better. Firstly, on IE, the stack isn't lost when window.onerror is called, so it's possible to get the call stack and arguments at each level of the stack. Secondly, it's very easy to get other kind of details (browser, version, page, etc.), which helps a great deal in aiding debugging.
However, masklinn's suggestion about wrapping code in try/catch blocks is probably not a good idea. This is because some interpreters (I know v8 does this) don't compile the code in such code-paths. May cause a performance hit.
As DavidPP mentioned, depending on the nature of your application, it might be a good idea to not record too much sensitive information. For example, Errorception doesn't record function arguments if the page is served over SSL.
troels is right - this does create a massive flood of errors. There are several ways to deal with this. What we do for example, is hide away errors from most third-parties - Facebook, Twitter, GoogleBot, GoogleAnalytics, etc. The rest of the errors can still be huge in number, so we group similar errors together based on several parameters like browsers, browser versions, possible variation in inline code line-numbers because of dynamic content, etc.
Also, as Kartificial pointed out, this is probably something you don't want to do on your own server. You want to move this out of your infrastructure, and distribute it if possible.
There are other concerns - some that come to mind are page load time, ensuring that your error catching code itself doesn't raise errors (or if it does, it doesn't affect your app in any way), and that of managing data-growth on the server. These are fun problems, but it's probably not worth re-inventing the wheel.
Monosyllabic answer is monosyllabic. You only state that you disagree, not why you disagree. Doesn't help take the discussion forward.
>> if you are going to try to come off as an authority
Why would you think I want to do that? I'm sharing my experience and my knowledge, and you are free to take it or discard it. Also, do you think it's better to attack me while making no real argument?
If you have to come across as having a real point, you are going to have to do better than that.
"use strict" is a good idea to ensure quality of your code, no doubt. However, the point I was making was about global pollution. Though "use strict" will help in ES5 browsers, a lint is the only comprehensive way to make sure there's no global pollution in older browsers.
The challenge you have mentioned is real, and is hard to crack. I certainly haven't solved the problem to my satisfaction yet. However, I'm rather far along the way. A lot of errors are classified as being irrelevant (I call it "muted", but that's a terminology thing), and the ones that are in your face are based on relevance and frequency. This is a very rudimentary way of deciding importance, but it's something. At least it's not a raw list of logs.
Improving the quality of "actionable information" as you put it will be the biggest (and most interesting and fun) challenge at Errorception. It'll get better over time.
I've heard about Muscula (and I'm reasonably sure they've heard about Errorception - it's a smallish world :) ), and I'm curious to know more about how they do what they do.
That said, the architecture isn't too different. Errorception is also built on Node and MongoDB. I am not a fan of JSONP (GET) for writing data (POST/PUT), mostly because I'm a stickler for HTTP semantics. Otherwise, without too much insight into what Muscula is doing, it certainly looks like we are very similar.
Browser/OS information is rather easy to get - it's all in the UA string. Errorception captures that already. :)
bdg, I mean no disrespect, but the matter is honestly not that trivial. Ultimately, you are right - it does come down to getting some queries right, but you quickly discover that it's an ongoing effort. Three months since I'm doing this, and even now I'd be happier if I could manage duplicates better. It's not a simple select query for sure.
XMPP is a connection-oriented stateful protocol. The connection setup process is very expensive: Connect, authenticate, advertise the list of supported client features, get the roster (contacts), and IIRC presence exchange, etc. Therefore, once you've established a connection, you really don't want it to break. Even just reconnecting is very expensive.
However, in the mobile scenario, regular connection breakage is the norm. What most mobile based clients will then do is proxy the XMPP connection on the server-side and connect to the client over HTTP instead. This is well defined in the BoSH spec (XEP:124). BoSH was originally designed for web-based clients, but happens to meet the need of the mobile use-case.
However, when it comes down to implementation, there are several optimizations that can be applied:
1. The roster exchange at the connection time is very expensive, and usually only sends data to the client that the client probably has already stored locally from a pervious session. Connection overhead can be reduced drastically if there was some way of versioning the roster and only transferring deltas. This was the OP was referring to. (Roster versioning, XEP:273).
2. Presence packets are one of the most chatty aspects of the protocol (x went offline, x is now online, etc). I've heard someone say that it constitutes about 80% of the packets on a typical connection, but this is anecdotal. In cases where the user isn't actively interacting with the client, having presence packets being sent all the time seems wasteful. One way to tackle this is to buffer up and de-duplicate the presence packets on the server, and send them in batches only when necessary. (For example, if x goes online, then offline, then online again, and then goes 'busy', the client only needs to know that x is busy.) I think this is what the OP was referring to when he mentioned the google:queue for delayed presence delivery. This alone can be a huge win for battery and bandwidth, since transferring data and processing it can be reduced drastically.
Aside: Presence is so chatty, that some mobile clients simply don't handle presence at all. Take WhatsApp for example. It doesn't show whether every person in your list of contacts is online. The assumption is that every user is online by the nature of the device, and this assumption works in the common cases. In the edge cases is where you'd need to buffer up messages. This reduces chattiness drastically, making the protocol seem much more lightweight. (WhatsApp is based on XMPP, but have spun it off into their own thing.)
Just thought I'd add these points to the discussion here, since there seemed to be some lack of understanding of the protocol. IMHO, the XML, as verbose as it is, isn't really the problem. The protocol itself is verbose and whether the transport uses XML or whatever else is of comparatively little consequence. This verbosity of the protocol (and not so much the format of data transfer) has its effect on battery life and bandwidth usage.