ralphm

The part where playing audio, including that from 3rd party sources, doesn't need Sonos to get any device usage data. However they still want it 'to improve their service', and you can't turn that off. Not accepting terms means that you'll never get firmware updates.

#3 is blue for all newborns

Note that the example was changed as a result of my initial comment.

As mentioned in another thread, don't do this blindly. If there are `Host` or`Match` blocks in the config, this new line will only apply to the last of those blocks.

Indeed. The page gives bad advise. If your config has `Host` blocks, like often in people's personal configs, or if you have a `Match` block, the new directive only applies to the last of those blocks in the config file.

And only the last `Host` entry in that config, if present.

Don't ever fix your `ssh_config` by appending stuff to the end of the file. The configuration syntax allows for block constructs without an explicit end marker (like `Match` and `Host`). Appending will cause all kinds of sadness.

I disagree. XML namespaces are URIs and give XMPP distributed extensibility. If you do this in JSON you are just replacing pointy brackets with curly ones.

The most valuable thing XMPP gains from using XML is namespaces. The way namespaces have been defined to work on top of XML, is what allows the protocol to be distributely extensible. I.e. anyone can define new protocol without having to clear this with a centralized body, not even the XSF.

If you'd want this property in a JSON-based wire protocol, you'd invariably going to end up with XML-in-curly-brackets. This is why developing with/for XMPP is slightly harder than a protocol that has a limited feature scope.

However, as Dave mentions elsewhere, one shouldn't have to deal with the wire protocol directly to use XMPP in your application. A proper library should abstract from that. Arguably in some platforms, that's still a weak spot.

Oh, I think we can agree that the situation is far from ideal. But this is to note that nothing has actually changed recently, as opposed to what has been written last week. With the exception of Voice over the old GTalk network, that is. And, of course, to highlight again that Google had the best way to describe why it is important to have choice, and then removed that choice.

Google did start Jingle and large part of their work ended up in the Jingle standards at the XMPP Standards Foundation. However, Google Talk and the old Hangouts took quite a while to move to the standardized version, and were never fully compliant. Also, in other areas, Google never quite interacted with the community and left major issues unresolved.

Basically all of the issues, perceived flaws or missing features attributed to XMPP in the old implementation of Hangouts were either misinformed or have seen development or new specifications in the XSF. Google never contributed to such discussions, with the exception of individual Googlers helping with Domain Name Associations (DNA, http://tools.ietf.org/html/draft-ietf-xmpp-dna-05).

In short, it is very unlikely the reasons for abandoning federation, or dropping XMPP altogether with Google Voice, are technical in nature.

“The technology of the last 10 years should have all been open to experimentation by developers without locking users in. There are a lot of developers who believe in this. It's central to the mission of WhatsApp, btw, so if you doubted that it could be lucrative, you should think again.”

WhatsApp has changed and extended their XMPP basis such that it is not even remotely interoperable. They are actively battling third-party implementations. Their server is not federated. How exactly are "open", "experimentation" and "without locking users in" central to WhatsApp's mission?

Makes much more sense for what, exactly?

There are a number of protocols that have been promoted for use in the Internet of Things arena, for example, including MQTT and XMPP. All of them have different strengths and weaknesses.

Cisco did a nice short overview of them with a minimalistic comparison: http://blogs.cisco.com/ioe/beyond-mqtt-a-cisco-view-on-iot-p.... In the comments there, Peter Wahler goes into some more depth on the advantages that XMPP brings to the table. Among them are stronger support for authentication (SASL) and transport security (TLS and channel binding for some SASL mechanisms) and federation (including connecting firewalled entities). And, of course, an established base of libraries, server implementations and deployment.

Other protocols have their own strengths in certain settings, and I can totally see hybrid solutions. For example, using MQTT for local use and XMPP for bridging networks.

While yes, it may not excel in beauty, when do applications developers really need to look at, or implement, wire-protocols? Embedding JSON inside an XML element seems to be one of the least horrible things you could encounter. Binary protocols or base64 encoded blobs or SDP are arguably worse.

As I mentioned in the other thread, if you want to make XMPP easier for application developers, things usually start with a well-defined API. If you want to, say, provide a simple API for doing publish-subscribe over XMPP, you don't really have to expose the intricacies of the XML-based wire-protocol. Most of the variables in this example (the addresses, the node identifier, the item identifier) can be exposed as simple attributes to a class representing a request, or as parameters to a function that performs the request.

However, normally, the payload format is still expressed as an embedded XML document, like Atom or the various payload formats for User Location, key exchange, etc., as defined in a number of XEPs.

Now, if your application just wants to be able to publish and/or subscribe to data easily expressible in JSON, why not just wrap that in a well-defined XML element, so that you can make your API as developer friendly as possible?

And, if you really want to go all the way, you could even do some server-side translation between XML and JSON payloads so that pure XMPP clients can still play without having to deal with JSON. There are some more advanced features in the XMPP Publish-Subscribe protocol to express such translations.

This has been discussed many times, but so far, no clear advantage of changing the wire-protocol, to be based on JSON instead of XML, has been shown. Especially if you want to retain distributed extensibility you will mostly end up with curly brackets instead of angle brackets. Sure, dealing with the DOM in the browser is not awesome, but in general this could be dealt with by having better library APIs instead of changing the wire-protocol.

That said, a minimal protocol addition like this, which just provides an element to wrap serialized JSON for payloads, definitely help with minimizing that DOM pain. I will propose standardizing this as a (very short) XEP (XMPP Extension Protocol) with the XMPP Standards Foundation.

I have understood that you should definitely try to keep the heap size under 32G as apparently the JVM can only compress pointers below that. Because we do event logging and our documents don't change after being indexed, some of the problems you mentioned (like merging) are not as pressing. And of course each log event has a timestamp and we can indeed limit our queries with them.

You're most welcome. Drop me a line any time.

I missed that, but that looks pretty awesome. Thanks for sharing!

In our case, most of the metrics come from the events flowing through Logstash, and statsd is on the machines running the Logstash server. Note that we are not using Logstash for shipping log events.

I did look at the greater landscape. What I found great about Graphite is the number of functions you have to massage the metrics. Not all metrics come in the same form (total number of bytes received since boot, or number of bytes received per second) and things like the `hitcount` and the `perSecond` (in the upcoming 0.10) functions really help.

It can indeed be slow, and this is usually a I/O issue. The Whisper storage backend does a lot of seeks, and people recommend using SSDs to deal with that. Also, you can have graphite-web just give you the (calculated) metric data for a particular query in JSON, and have it rendered client-side. http://graphite.readthedocs.org/en/latest/tools.html lists a few.

Finally, we are investigating other storage backends for more fault tolerance. Probably we'll settle on something based on Cassandra, like http://blueflood.io/.

What I found most important is to monitor Elasticsearch while doing that tuning. That's when I set up Graphite and StatsD and https://github.com/ralphm/vor.

First of, you need to make sure Elasticsearch can lock a chunk of memory (using mlock). About half of the available RAM is a good size, as other system processes need some memory, too, and not everything is on the heap.

You want to look for how many items you are indexing and how much of the heap the field data cache is using while doing queries. By default ES tries to keep the total heap size at about 3/4 of the allocated memory. The types of queries are important, too. E.g. if you do faceting or sorting on fields that have many different values, this will fill up the field data cache in no time.

Is that the kind of information you're after? I can go into in more detail if you have more specific question.

Yeah, it takes a bit of tuning, depending on what you want to do with Elasticsearch. There are so many different use cases. I found that especially keeping the heap size for field data down to 40% helped quite a bit, in my case.

It should ship with one, but otherwise see here http://mcabber.com/hg/index.cgi/file/dd8ae0abfc68/mcabber/mc...

I'm pretty fond of MCabber (http://mcabber.com/), a full featured XMPP client with proper Multi-User Chat (MUC) support. I use it inside a screen(1) session, next to irssi.

Sorry, but the new Hangouts does not support federation. The old GTalk network, though, does. If a message comes into the latter from non-Google servers, they only show up in connected XMPP clients, not on Android or GMail after upgrading to Hangouts. If the intended recipient does not use a 3rd party XMPP client and has fully upgraded, he will never see the message!

For outbound traffic some odd stuff is going on. Presence from all Hangouts endpoints still propagates to GTalk and thus federates. Messages can also be sent. But again, that's one way and replies are not delivered to Hangouts. Additionally, XMPP iq-type requests to Hangouts endpoints are not responded to, violating the core XMPP spec.

Presence subscriptions don't have to be symmetrical in XMPP, and indeed you can even have contacts on your roster that don't share presence in either direction. As for exchanging messages, as far as I know Google's implementation is the only one that doesn't allow that without presence subscription. All others do.

In fact, this caused presence subscription requests to be the only attack vector in terms of spam in Google talk, which some argue makes it harder to combat. Mostly because there is less data available to detect malicious behaviour.

Please read that first document and also my remark about SIFT, which basically allows for delaying or dropping presence to cut down on antenna use and battery consumption.

At least Microsoft has XMPP federation support in Lync: http://en.wikipedia.org/wiki/Microsoft_Lync_Server#XMPP. Otherwise, yes, Skype and Facebook should add federation support. The actual protocol isn't even that important, as long it can be implemented freely.

I should have made the link to the document on XMPP on Mobile Devices more explicit: http://xmpp.org/extensions/xep-0286.html. In short, the use of compression in the TLS layer negates the oft stated verbosity of XMPP. It really isn't the problem you think it is. More info: http://stpeter.im/journal/1384.html. I might be a fanboy, but I do know what I'm talking about.