Beyond file transfer

Following the official release of the latest GTalk client, I decided to scratch the surface of its file transfer implementation. Thanks to Brian McBarron’s answer posted on the JSF list explaining how to capture a detailed log of the client’s operation (run the client with the following arguments: /log verbose tstamp thread file), I was able to confirm that the GTalk client is indeed leveraging Google’s implementation of Jingle to control file transfer. This endorsement by Google is another commitment to open standards. As shown bellow, the receiver party’s presence is probed before the transfer, in order to make sure the target client understands the transfer protocol. This is returned in the presence stanza’s capabilities extension. It is interesting to note that the capability is named “share” rather than transfer.

<presence to="juliet@gmail.com" type="probe" />

<presence to="romeo@gmail.com/Talk.v969557A95E" from="juliet@gmail.com/Talk.v95286273DB">
  <priority>0 </priority>
  <c xmlns="http://jabber.org/protocol/caps" ext="share-v1 voice-v1" ver="1.0.0.95" node="http://www.google.com/xmpp/client/caps" />
  <x xmlns="jabber:x:delay" stamp="20060817T19:50:07" />
  <status>available </status>
  <x xmlns="vcard-temp:x:update">
    <photo>ae825c56c617f83a577b0cff43611d2076358c20 </photo>
  </x>
</presence>

The next exchange uses the actual Jingle signaling to negotiate a transfer session between the parties. I have only shown the session part, as the point-to-point transport negotiation is identical to a voice transport negotiation. Note again the description namespace for the application.

<iq to="juliet@gmail.com/Talk.v95286273DB" type="set" id="31">
  <session xmlns="http://www.google.com/session" type="initiate" id="598724353" initiator="romeo@gmail.com/Talk.v969557A95E">
<description xmlns="http://www.google.com/session/share">
  <manifest>
    <file size="34314">
      <name>
        About.jpg
      </name>
      <image width="150" height="133"/>
    </file>
  </manifest>
  <protocol>
    <http>
      <url name="source-path">
        /temporary/6b82cd1ca2f333d99bad2ea07ce33f33/
      </url>
      <url name="preview-path">
        /temporary/9c6b15f343aaabea3c6a106eb72b4c80/
      </url>
    </http>
  </protocol>
</description>
<transport xmlns="http://www.google.com/transport/p2p"/>
  </session>
</iq>
<iq to="romeo@gmail.com/Talk.v969557A95E" id="31" type="result" from="juliet@gmail.com/Talk.v95286273DB"/>
<iq to="romeo@gmail.com/Talk.v969557A95E" type="set" id="49" from="juliet@gmail.com/Talk.v95286273DB">
  <session type="transport-accept" id="598724353" initiator="romeo@gmail.com/Talk.v969557A95E" xmlns="http://www.google.com/session">
    <transport xmlns="http://www.google.com/transport/p2p"/>
  </session>
</iq>
<iq to="juliet@gmail.com/Talk.v95286273DB" id="49" type="result"/>

FIle transfer is an important adjunct to Jingle, as it confirms the signaling can be used well beyond voice or other video communication. This is not revolutionary per say, as session negotiation and signaling has been around with SIP for some time now. But only proprietary extensions of the SIP signaling have been so far implemented when it comes to widely deployed file transfer. The use of Jingle bears the promise of a much wider adoption for a standard based file transfer negotiation. Obviously, this is only Google’s implementation of Jingle, but except namespaces, nothing in it cannot be made into a JEP. And this is what the authors of this file transfer are committed to do.

Coming back to my initial remark about the GTalk client’s naming this new feature “share”, I believe this update is only the pre-release of a larger scoped real-time experience. Brian’s post on the JSF mailing list gives a good explanation of the layered design applied to the file transfer application. By adopting this architecture, I believe Google is effectively enabling far more than just file transfer:

• the transport protocol called “PseudoTCP” which is used in the p2p exchange is a Google re-implementation of TCP using UDP packets. The layered design would allow replacing this proprietary transport by a standard, such as SCTP, without disrupting the network stack so much.
• the application protocol is HTTP enables interesting things such as download previews of images, resume transfers, compress files, etc. Without being full fledge web servers, a GTalk client becomes an important part in enabling a real time collaboration application. Linking it to a workstation’s browser through some toolbar plug-in is probably not that difficult, and would makes an XMPP backed real time photo sharing and comment experience much more compeling than their web only siblings.

Although this latest release has received unjustified bashing from many ignorant self proclaimed visionaries, I believe on the contrary that it is paving the way toward wider scoped real time standards-based sharing services for communities, open to any and all that wish to interoperate with them.

Technorati Tags: XMPP, Jingle, Conversation spaces, Session signaling, File sharing, Google Talk, Antecipate

Not microformated here!

Most people naturally find it more enjoyable to speak than to listen. Which developers would not like to be known as the one who wrote this killer app that the whole company now relies on, rather than simply the guy who made the suggestion to use somebody else’s? If we are honest with ourselves, most of us, “Y” chromosomed beings, usually find it hard to admit that somebody else had better idea than we did, or did as good a job implementing it than we could have done…

Even organizations with an open mind to leveraging external ideas may simply be unaware that what they need is already available. There is very often a certain amount of "herd instinct" driving “not invented here” in these groups of peoples. Even open-source communities don't always know that what they're creating has already been done, and even if they do know, many reasons can prevent them from using an existing solution other than NIH syndrome itself. A way to diagnose NIH syndrome is to go through these other reasons and eliminate them. If none of them apply, then you are probably looking at a real NIH syndrome case! The only valid reasons are:

• No existing suitable solution can be found, not even one which may be adaptable.
• A close-to-suitable solution is found, but solving 90% of the problem is not sufficient. In this situation, if the "90%" solution cannot be extend or customize it to fulfill 100% of the specification, then the potential solution is rejected.
• A close-to-suitable solution is found, but the work to extend or customize it to fulfill 100% of the specification is more than the work to reproduce it entirely. Again, the potential solution is rejected.
• A suitable solution is found, but one that is not compatible with existing or chosen standards. This solution is rejected.

…Atom answers more than 90% of what is required for an IM logging format…

Through this lengthy introduction I wanted to express my deep agreement with Hal’s answers to the legitimate question he raised on the use of Microformats in the XMPP standard: simply put, they usually do not make sense in a real time communication context. Microformats are a typical example of very narrow minded NIH syndrome. They initialy came up to solve rendering issues in a static location based web, when information was not available in an XML form (vCard, calendar). The initial authors found smart to leverage Microformat to lessen the shortcomings of existing crawler’s technologies, and thus added keywords to published information. Again, this was a valid move for static content. But when it comes to IM logs, I believe Microformats are definitively not appropriate. There is at least one existing XML markups available that would do it better than any coming Microformat: the Atom feed standard.

If one goes beyond the word “syndication” in the standard’s name, it can easily check how Atom answers more than 90% of what is required to store and communicate content and meta-data for an IM logging system! It just need to run Atom’s capabilities through the above reasons’ list…

Atom’s feeds and entries contain three elements:

• A unique identifier, which can be as simple as the URI of a blog entry or a truly unique 128-bit message stanza’s thread.
• A title, which expresses a short, human readable subject line for the entry, and can be a blank string.
• A time-stamp which indicates when the recorded feed or entry occurred.

A feed or entry can have multiple author elements along with zero or more contributor elements. These later elements identify individuals who might have contributed to the production of the feed or entry. Both the author and contributor elements are fully extensible, to provide as much detail about the author or contributor as deemed appropriate. Further, Atom provides a robust, flexible, and consistent content model capable of supporting plain text, escaped HTML, well-formed XHTML, arbitrary XML, base-64 encoded binary content, and URI pointers to content not included directly within the feed.

Finally for those who would be wondering about multimedia, Atom supports elaborate enclosures which have already been used in application such as podcasting, and would provide an excellent ground for future Jingle applications logging.

I am sure everyone will also understand the added value of the existing and growing support of Atom directly in the browser for rendering, and in the feed aggregators for syndication. That alone obsoletes many of the fallacious arguments used in some comments to Hal’s post to sustain the use of Microformats.

To conclude, I believe Atom provides more than 90% of what is needed for a superior IM logging format. As its transport over XMPP is already under way, it makes sense for the JSF to spend time defining a usage mapping for this new IM logging scope. Would it be as much fun as rewriting a new markup? No, almost certainly not. Would it be more efficient and cost effective? Quite certainly yes.

Technorati Tags: XMPP, Jabber, Atom, Microformat, Interoperability, Instant messaging, Antecipate

Mobile presence dial-tone

The word is out about Jaiku. Some speak of “mobile social networking”, other mention “rich presence”. I would simply call it another perfect example of XMPP’s extreme flexibility and adaptability.

Jaiku combines a well conceived Symbian client with an XMPP back-end, and a web based front end service. The service is sleek and easy to register with, offer a simple and uncluttered interface, and all the necessary scripts to include your mobile presence in any web page. The client, for the time being limited to Nokia Series 60 Second Edition phones, integrates cleverly with the phone directory, converting it into a “presence enabled” directory. The client is also aware of many phone events and functions, such as the calendar. It appears the Jaiku’s team has slightly extended the XMPP presence stanzas in order to accommodate a richer set of information to includes

… an IM-style away line, your phone profile (ring volume, vibrate), location (country, city/region, neighborhood), Bluetooth devices around, upcoming calendar events, and the duration how long your phone has been idle.

Although the information released in the enhanced presence states may be perceived as disclosing a potentially large amount of your privacy, the service gives a perfect example of presence as the new dial tone. Presence being embedded in the phone directory, it is displayed whenever you want to place a call to one of your contacts.

This further reinforce, in my opinion, the advantages of XMPP. XMPP is a presence based protocol. And Jaiku is a perfect example of a non IM XMPP application natively presence enabled.

Technorati Tags: XMPP, Jabber, Presence, Antecipate