Profile

Cover photo
Brian Aker
Works at Hewlett-Packard
Attended Antioch College
Lives in Seattle
692 followers|51,869 views
AboutPostsPhotosVideos

Stream

Brian Aker

Shared publicly  - 
10

Brian Aker

Shared publicly  - 
 
The basics: Added gearman_task_is_finished() Improved SSL support. Exceptions are now supported. gearmand excepts its root CA via the environmental variable GEARMAND_PORT.  libgearman will now except GEARMAND_CA_CERTIFICATE,...
6
1
Joshua Turmel's profile photo

Brian Aker

Shared publicly  - 
 
This quite sad to read.
 
Google defends dropping chat federation with inaccurate and misinformed comments on the underlying protocol (XMPP) and blaming others for not joining.

Apparently, all the of the (good) sentiments behind the reasons for choosing XMPP as the protocol for Google Talk (https://developers.google.com/talk/open_communications) are no longer the driving force behind the decision making regarding its replacement Google Hangouts. All that talk about Client Choice, Service Choice and Platform Choice has been replaced with "if the other big players don't play, why should we?". So all those "thousands of other ISPs, universities, corporations and individual users" Google Talk used to federate with are no longer important.

On top of that, XMPP is blamed for not keeping up with the times:

"When XMPP was designed, smartphones and social networks didn't exist. Yet both trends essentially transformed communication but the standard remains unchanged. For example, mobile has several requirements around bandwidth and battery that are simply not part of the standard. And audio and video integration are not well defined," [a Google spokesperson] said.

This glances over the the fact that the X in XMPP stands for eXtensible, which still results in proposals for new protocol extensions every month. The XMPP Council, which I am currently serving on, watches over XMPP extensions in the XEP series (http://xmpp.org/xmpp-protocols/xmpp-extensions/) of the XMPP Standards Foundation. However, as XMPP is built on distributed technologies, everyone can invent their own protocol extensions in private, too. Something that Google should be fully aware of, as they have created a bunch of their own protocol additions, of which some are documented here: https://developers.google.com/talk/jep_extensions/extensions.

To go into even more depth, at various times, battery and bandwidth constraints for mobile use, have been discussed within the XMPP community at several times, since at least in 2008 and possibly before, with protocol proposals like Roster Versioning (XEP-0273, now part of RFC 6121), SIFT (XEP-0273) and background information on XMPP on Mobile Devices (XEP-0286).

Meanwhile, Google never participated in any of these discussions (https://plus.google.com/116276248303121270590/posts/V7LzUzj8R4D). Instead, they invented their own protocol (google:queue) for delayed presence delivery, much like but slightly simpler than what SIFT proposes. Had Google just participated, that protocol had likely been remade into a true XEP, for broader use in the community. This would have prevented, for example, Facebook, from also creating its own protocol for the same thing (https://bugs.freedesktop.org/show_bug.cgi?id=38943).

Of course none of these concerns for mobile are applicable for server federation. As far as I know, the Google Talk client on Android doesn't even use XMPP as the client-to-server protocol.

Google did cooperate with the XMPP community on standardizing Jingle (http://xmpp.org/extensions/xep-0166.html), a suite of protocol extensions for initiating and managing peer-to-peer media sessions between two XMPP entities. Ironically, this includes *audio and video integration", the very thing Google now says is not well defined, where Google was by far the largest driver behind it. And then Google Talk also never fully implemented the standardized protocol, causing other implementations to add custom, non-standard, workarounds.


Likewise, there are several proposals and even IETF drafts (for enhancing network security, including spam prevention, that Google didn't bother to implement. As an example, whereas as many other server operators would have wanted to start verifying X509 certificates on the TLS encrypted connections between servers, Google still doesn't check certificates or serve up properly signed ones themselves, allowing rogue servers to come in play.

The XMPP community even tried to accommodate some of the harder issues with serving up proper certificates for large numbers of hosted domains, explicitly including Google Talk, resulting in this IETF draft: http://tools.ietf.org/html/draft-saintandre-xmpp-dna-02.

From personal experience with building federated social networks on top of XMPP at Mediamatic Lab, I can name several other protocols that would benefit some of the newer features in Google Hangouts, including Publish-Subscribe (XEP-0060) and the related Personal Eventing Protocol (XEP-0163), that Google just ignored.

How didn't the standard (XMPP) change again?

As +Peter Saint-Andre was quoted in the TechHive article, we will just move forward.
2

Brian Aker

Shared publicly  - 
 
I believe this is a legit request. Early google culture had this element to it, so I wouldn't be surprised if she was just sticking to what she knows has worked in the past.
 
Surely I'm not the only person to think this is a rather well executed disguised downsize? Everyone's talking about the silly policy, no-one's paying attention to the inevitable headcount reduction. "Hey, we didn't lay anyone off! We just implemented a new policy and some employees chose to depart. Of course we're doing great!"
1
Dan Shick's profile photoAntony T Curtis's profile photoMark Atwood's profile photoEric Hopper's profile photo
6 comments
 
+Eric Hopper  that is, in general, what CEOs do.  Cargo-cult management, cargo-cult process, cargo-cult leadership, and cargo-cult results.

Brian Aker

Shared publicly  - 
 
Star light, star bright, first star I see to tonight!
7
Have him in circles
692 people
Peter Zaitsev's profile photo
Daniel Saito's profile photo

Brian Aker

Shared publicly  - 
 
Skill unlocked: standing!
14
Russell Nelson's profile photoDavid Lane's profile photoTim O'Reilly's profile photoPatrick Galbraith's profile photo
4 comments
 
Next skill to be mastered: falling.

Brian Aker

Shared publicly  - 
 
FUD lead engineering decisions that result in incompatibility. http://t.co/HkD4YMW111
1

Brian Aker

Shared publicly  - 
4
People
Have him in circles
692 people
Peter Zaitsev's profile photo
Daniel Saito's profile photo
Work
Occupation
Engineer
Employment
  • Hewlett-Packard
    Fellow, present
  • Sun Microsystems
    Distinguished Engineer
  • MySQL AB
    Director of Architecture
  • Slashdot
    Senior Architect
  • Cobalt
    Senior Architect
Places
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Currently
Seattle
Previously
Iowa City - Yellow Springs - Lexington, Kentucky
Links
YouTube
Contributor to
Story
Tagline
This will go down on your permanent record.
Introduction
Bragging rights
http://en.wikipedia.org/wiki/Brian_Aker
Education
  • Antioch College
  • University of Iowa
Basic Information
Gender
Male
Other names
Krow