asynchronous cancellation (when compared to deferred) is only recommended in scenarios where the thread does not share any data, semaphore or conditional variables with other threads. The target thread tends to cleanup any data within the thread cleanup handlers via pthread_cleanup_pop(). If not, the entire application might end up going down. Async cancellation has a very narrow application scope imho.
It does not seem all that impossible now, now that Skype has been integrated into Facebook. From what I hear, they have stripped down most of skype and provided javascript apis for the facebook web app.
Before that, I always used to wonder how could one take all of signaling protocol (like the monstrous SIP, XMPP etc) and media (RTP) and cram all of it into the browser.
Pretty different boats. Facebook/Skype requires a separate binary installation. Google Talk/Hangouts/etc currently requires Google's "Voice and Video plugin", which at least just integrates into Chrome rather than installing separate executables, but for the sake of this discussion, they're functionally equivalent.
Packing the necessary tools into a toolkit that a browser can utilize first-rate is, as you pointed out, a different challenge. Not sure what SIP or XMPP are "monstrous" though.
> Not sure what SIP or XMPP are "monstrous" though.
Both SIP and XMPP are way beyond "monstrous", hundreds of specs, and most implementations are not really interoperable beyond the very basics. (XMPP is still barely at the level irc reached almost 20 years ago, and that is after ten years of and ever growing and changing list of specs, which is actually the problem).
Well, I am not sure why Google went with XMPP when the rest of the telecom and networking industry is gravitating towards IETF SIP as signaling protocol. There are so may overlaps in both of them in the sense that they use the same components such as SDP and ICE. Can anyone from Google or otherwise throw some more light on
- Why Google prefers XMPP over SIP
- In what areas XMPP is better that SIP
I am not stating that one is better than the other, but would like to understand the core differences and advantages.
Also with Google moving on with XMPP and other major vendors converging on SIP, where do you see the inter-operability issue heading towards?
I guess SIP has weak support for Instant Messaging, which was the primary use case for Google Talk before video chat came along.
On the other hand the Jingle spec [1] contains many references to SIP:
"Furthermore, Jingle is not intended to supplant or replace existing Internet technologies based on the Session Initiation Protocol (SIP; RFC 3261). Because dual-stack XMPP+SIP clients are difficult to build, Jingle was designed as a pure XMPP signalling protocol. However, Jingle is at the same time designed to interwork with SIP so that the millions of deployed XMPP clients can be added onto existing Voice over Internet Protocol (VoIP) networks, rather than limiting XMPP users to a separate and distinct network."
If this had happened for email, we would have had to deal with a myriad of different clients, servers and 'interworking' gateways.
I really don't understand why the likes of Google, Apple, Microsoft and the telcos can't agree on a standard. Guess business reasons are behind this. After all, walled gardens are great if you are the incumbent, it's how Skype got to be so valued.
If this had happened for email, we would have had to deal with a myriad of different clients, servers and 'interworking' gateways.
That was the networking prior to the wide adoption of IP and SMTP. There were DECnet mail clients, and clients for various other networking protocols, and users needed to know explicit bang-path routes and gateways.
Seeing this churn and this fragmentation is unpleasant, but it also means that you can see rapid advances and new features and different approaches. Once the market matures and the churn settles down, we'll see more of this sort out toward protocol consolidation.
In general, areas with high churn are some of the most interesting parts of the whole computer business. They're among the least mature, and often with the most innovations.
I hadn't looked at it from this perspective, thank you for the enlightenment. I'm just too impatient.
What irks me is that the IETF keeps banging away at protocols to solve issues like the transition from PSTN to IP (e.g. ENUM), or IM interoperability, but then nobody really implements them, or as in the case of ENUM, the incumbent telcos, at least in the USA, sit on it forever. Or some startup cooks up their own solution and kills it, like Skype.
I'm all for interoperability sorting itself out, but it does not seem to happen in the messaging/real time communications space. We still have SMS, a gazillion IM protocols, and many isolated islands of video calling. Skype, Qik, MSN, Yahoo, FaceTime, Google, I could go on. On top of that is the confounding issue of different audio and video codecs and whatever patent issues surround them. A formidable gordian knot, of which it will be interesting to see how it will be cut - if ever.
I'm far too impatient as well, I suppose. It seems to me (from the armchair where I quarterback) that IM interoperability isn't happening not because companies prefer the advantages of their chosen protocol, but because they simply want to "be the platform." I can't imagine a better advantage than actually being able to talk with any of my friends on any other client.
If email hasn't proven a standard can be beneficial to everyone, I don't know what would.
XMPP is much more extensible than SIP. Presence, messaging, and IM work much better in XMPP. There are extensions for archiving messages, return receipts, etc. There are extensions for file transfer.
There are extensions for vCards. There are extensions for PubSub.
XMPP works over HTTP using BOSH. It can also work over SOCKS.
Apache/Google Wave uses XMPP for federation. It is just flat out more extensible and featureful. Just like the acronym stands for: Extensible Messaging and Presence. It does a whole lot more than just IM or just VoIP.
