Patrick Schoenfeld: Cool PHP-Code.
Did you know that in PHP you can write something like that:
echo sPrintF(_("Bla bla bla: %s"), $bla))
And yes, they do use echo to output the result of sprintf.
Update: So i got this great comment. The commentator wants to point out that the senseless use of "echo sprintf" is because of gettext. He says "That's simply the way you use gettext." But this is simply not true. The difference between printf and sprintf is that the first one outputs the string, while the second one returns it. That means that in the above example printf could be used (instead of sprintf) without a useless echo call in front of it. The reason for using sprintf (and eventually the reason because you find it in a lot of applications using gettext) is that you can use it to fill a variable with the translated string or to use the string in-place. A common use-case for this is to handle a translated string to a template engine, for example.
$test = "foobar";What makes me frighten is that this actually used, e.g. by this code snippet which exists (in a similar form) in an unnamed PHP-project:
$test = sTr_RePlace("bar", "baz", $test);
$x = sPrinTf("%s is strange.", $test);
pRint $x . "\n";
eCho "foo";
echo sPrintF(_("Bla bla bla: %s"), $bla))
And yes, they do use echo to output the result of sprintf.
Update: So i got this great comment. The commentator wants to point out that the senseless use of "echo sprintf" is because of gettext. He says "That's simply the way you use gettext." But this is simply not true. The difference between printf and sprintf is that the first one outputs the string, while the second one returns it. That means that in the above example printf could be used (instead of sprintf) without a useless echo call in front of it. The reason for using sprintf (and eventually the reason because you find it in a lot of applications using gettext) is that you can use it to fill a variable with the translated string or to use the string in-place. A common use-case for this is to handle a translated string to a template engine, for example.
The 
I've just read Vincent Sanders' 
Every now and then, people ask me why Debian? Why, among so many projects to choose from, I first liked, then got into, and finally I got committed into Debian, and not anything else?
Of course, one of the main points back in 2000-2001 when I started using it, and still to this very day is a strong identification with the ideological side. Yes, I am a strong Free Software believer, and Debian is what best suites my ideology.
Still, I did not only get into Debian because of this And I was reminded about this by an article in this month's 
Best wishes to everyone in Debianland for a happy and prosperous Gujarati New Year (Vikram Samvat 2066, called Plava)
This year the local mandirs continued their recent trend of coordinating their Diwali/new year plans and there was a big mela planned. Unfortunately the weather didn't really cooperate but the kids got to manhandle some explosives and after all isn't that the reason for the season?
Presentwise, I got a 
plus a much-needed woolen hat.
I've decided that I am going to quit my job. It's a soul-sucking dead end but in these tough economic times it pays bills so I've agonized about this for a long time. This was supposed to be the year we moved out of Jersey City but it has yet to happen. And it never will unless I take some sort of decisive action. So I'm going to do it. Wish me luck!
A few of us are working on 
I am currently making a shared library out of some existing C code,
for eventual inclusion in Debian. Because the author wasn't thinking
about things like ABIs and APIs, the code is not too careful about
what symbols it exports, and I decided clean up some of the more
obviously private symbols exported.
I wrote the following simple script because I got tired of running grep by hand.
If you run it with
The first Telepathy session session on Saturday evening at the Boston GNOME Summit was very much of a Q&A where myself and Will answered various technical and roadmap issues from a handful of developers and downstream distributors. It showed me that there s a fair amount of roadmap information we should do better at communicating outside of the Telepathy project, so in the hope its useful to others, read on
MC5
Ted Gould was wondering why Mission Control 4 had an API for getting/setting presence for all of your accounts whereas MC5 does not. MC5 has a per-account management of desired/current presence which is more powerful, but loses the convenience of setting presence in one place. Strictly speaking, doing things like deciding which presence to fall back on (a common example being if you have asked for invisible but the connection doesn t support it) is a UI-level policy which MC should not take care of, but in practice there aren t many different policies which make sense, and the key thing is that MC should tell the presence UI when the desired presence isn t available so it could make a per-account choice if that was preferable. As a related side point, Telepathy should implement more of the invisibility mechanisms in XMPP so it s more reliably available, and then we could more meaningfully tell users which presence values were available before connecting, allowing signing on as invisible.
Since MC5 gained support for gnome-keyring, its not possible to initialise Empathy s account manager object without MC5 prompting the user for their keyring password un-necessarily (especially if the client is Ubuntu s session presence applet and the user isn t using Empathy in the current session but has some accounts configured). Currently the accounts D-Bus API requires that all properties including the password are presented to the client to edit. A short-term fix might be to tweak the spec so that accounts don t have to provide their password property unless it s explicitly queried, but this might break the ABI of tp-glib. Ultimately, passwords being stored and passed around in this way should go away when we write an authentication interface which will pass authentication challenges up to the Telepathy client to deal with, enabling a unified interface for OAuth/Google/etc web token, Kerberos or SIP intermediate proxy authentication, and answering password requests from the keyring lazily or user on demand.
Stability & Security
Jonathan Blandford was concerned about the churn level of Telepathy, from the perspective of distributions with long-term support commitments, and how well compatibility will be maintained. Generally the D-Bus API and the tp-glib library APIs are maintained to the GNOME standards of making only additive changes and leaving all existing methods/signals working even if they are deprecated and superseded by newer interfaces. A lot of new interfaces have been added over the past year or so, many of which replace existing functionality with a more flexible or more efficient interface. However, over the next 4-6 months we hope to finalise the new world interfaces (such as multi-person media calls, roster, authentication, certificate verification, more accurate offline protocol information, chat room property/role management), and make a D-Bus API break to remove the duplicated cruft. Telepathy-glib would undergo an ABI revision in this case to also remove those symbols, possibly synchronised with a move from dbus-glib to GVariant/etc, but in many cases clients which only use modern interfaces and client helper classes should not need much more than a rebuild.
Relatedly there was a query about the security of Telepathy, and how much it had been through the mill on security issues compared to Pidgin. In the case of closed IM protocols (except MSN where we have our own implementation) then we re-use the code from libpurple, so the same risks apply, although the architecture of Telepathy means its possible to subject the backend processes to more stringent lockdowns using SElinux or other security isolation such as UIDs, limiting the impact of compromises. Other network code in Telepathy is based on more widely-used libraries with a less chequered security history thus far.
OTR
The next topic was about support for OTR in Telepathy. Architecturally, it s hard for us to support the same kind of message-mangling plugins as Pidgin allows because there is no one point in Telepathy that messages go through. There are multiple backends depending on the protocol, multiple UIs can be involved in saving (eg a headless logger) or displaying messages (consider GNOME Shell integration which previews messages before passing conversations on to Empathy), and the only other centralised component (Mission Control 5) does not act as an intermediary for messages. Historically, we ve always claimed OTR to be less appealing than native protocol-level end-to-end encryption support, such as the proposals for Jingle + peer to peer XMPP + TLS which are favoured by the XMPP community, mostly because if people can switch to an unofficial 3rd party client to get encryption, they could switch to a decent protocol too, and because protocol-level support can encrypt other traffic like SRTP call set-up, presence, etc.
However, there is an existing deployed OTR user base, including the likes of Adium users on the Mac, who might often end up using end to end encryption without being aware of it, who we would be doing a disservice by Telepathy not supporting OTR conversations with these people. This is a compelling argument which was also made to me by representatives from the EFF, and the only one to date which actually held some merit with me compared to just implementing XMPP E2E encryption. Later in the summit we went on to discuss how we might achieve it in Telepathy, and how our planned work towards XMPP encryption could also help.
Tubes
We also had a bit of discussion about Tubes, such as how the handlers are invoked. Since the introduction of MC5, clients can register interest in certain channel types (tubes or any other) by implementing the client interface and making filters for the channels they are interested in. MC5 will first invoke all matching observers for all channels (incoming and outgoing) until all of them have responded or timed out (eg to let a logger daemon hook up signal callbacks before channel handling proceeds), all matching approvers for incoming channels until one of them replies (eg to notify the user of the new channel before launching the full UI), and then sending it to the handler with the most specific filter (eg Tomboy could register for file transfers with the right MIME type and receive those in favour to Empathy whose filter has no type on it). Tubes can be shared with chat rooms, either as a stream tube where one member shares a socket for others to connect to (allowing re-sharing an existing service implementation), or a D-Bus tube where every member s application is one endpoint on a simulated D-Bus bus, and Telepathy provides a mapping between the D-Bus names and the members of the room.
In terms of Tube applications, now we ve got working A/V calling in Empathy, as well as desktop sharing, and an R&D project on multi-user calls, our next priority is on performance and Tube-enabling some more apps such as collaborative editing (Gobby, AbiWord, GEdit, Tomboy ?). There was a question about whether Tube handlers can be installed on demand when one of your contacts initiates that application with you. It d be possible to simulate this by finding out (eg from the archive) which handlers are available, and dynamically registering a handler for all of those channel types, so that MC5 will advertise those capabilities, but also register as an approver. When an incoming channel actually arrives at the approval stage, prompt the user to install the required application and then tell MC5 to invoke it as the handler.
Colin Walters asked about how Telepathy did NAT traversal. Currently, Telepathy makes use of libnice to do ICE (like STUN between every possible pair of addresses both parties have, works in over 90% of cases) for the UDP packets involved in calls signalled over XMPP, either the Google Talk variant which can benefit from Google s relay servers if one or other party has a Google account, so is more reliable, or the latest IETF draft which can theoretically use TURN relays but its not really hooked up in Telepathy and few people have access to them. XMPP file transfers and one-to-one tube connections use TCP which is great if you have IPv6, but otherwise impossible to NAT traverse reliably, so often ends up using strictly rate-limited SOCKS5 -ish XMPP proxies, or worse, in-band base64 in the XML stream. We hope to incorporate (and standardise in XMPP) a reliability layer which will allow us to use Jingle and ICE-UDP for file transfers and tubes too, allowing peer to peer connections and higher-bandwidth relays to enhance throughput significantly.
Future
Ted Gould had some good questions about the future of Telepathy
This entry was originally posted in slightly different form to 