February 11, 2010

You don’t need Kopete Facebook plugin anymore

In May 2008, Facebook announced that they were planning to add XMPP (a.k.a Jabber), the standard messaging protocol behind Google Talk and other chat programs, to their Facebook Chat solution.

In May 2009, seeing that nothing happened, I announced that I was working on Facebook support for Kopete and released a prototype on github. The plugin was not perfect, and it was talking to Facebook using non-standard ways (including html scrapping!), but allowed people to see their contacts and chat.

Yesterday, Facebook finally announced XMPP support. This means various things:

  • You can connecto to Facebook chat using any XMPP compatible program: Kopete (using the standard Jabber plugin)
  • My Kopete plugin is not longer needed and will be deprecated

To setup it with Kopete just add a Jabber account like this:

Kopete preferences for Facebook chat

This is a great move from Facebook. As Lars already mentioned, the Web 2.0 sites have brought lot of innovation and fresh wind to the Web. However, they have ignored interoperability a lot, and he is right, you need “connectors” to get your data.

The Web 2.0 has changed the way users store their data. Now it is everywhere. Without good interoperability we are only adding complexity to users.

If your website implements contacts, don’t forget to add a url with a http accessible vCard list. If your site implement events, provide an url with iCal entries. Google has done a good job with Google Calendar and Google Mail. Worth to mention the urls with calendar/contact entries can be “secret urls” which contain a long random string, but require no authentication, which makes it easy to add to your desktop mashup utilities, organizers, plasmods, etc.

Facebook still could do more. They invented a whole new email system. But they forgot to offer IMAP/SMTP interoperability with it. I am not sure either (feel free to correct me) whether I can generate a secret url with iCal entries of Facebook events as well.

Anyways, big thanks to whoever is responsible of getting this done. You did a big favor to the Internet itself.

As for Kopete. As protocols start to use XMPP, the need of hiding XMPP for the end user arises. The account wizard should display the services known by name, and do the XMPP setup with the known preferences. May be something I can work on now that I don’t need to maintain the protocol anymore. And I almost forget: we need a way to migrate current users of the plugin.

May 24, 2009

Facebook on Kopete, take II

Last week I blogged about Facebook support for Kopete, just after I was able to see my buddies for first time on the screen.

Since then I have made some improvements to message handling and other code cleanups. The code is now available in a git repository at github.

As KDE’s svn trunk is frozen, I will keep it there for now.

You can get packages for openSUSE Factory (version 0.1.2). I gave up trying to build it for openSUSE 11.1, as Kopete API has changed quite a bit. However the package may build on 11.1 plus the KDE 4.2+ repositories. You need libqjson from Flavio Castelli installed (or -devel package if you want to build it).

Roadmap for next 0.1.3:

  • Add caching to avoid downloading the pictures every 3 minutes.
  • More bugfixes

Roadmap for later:

  • Look into adding , searching, and other stuff.

Be aware. This is weeks-old-code. It has not been tested much and has lot of debug messages. Use it if you are a early adopter only.

May 20, 2009

Facebook support: First milestone reached

So, I have been working some weeks on this, and today I reached the first “usable” point. Screenshot:

facebook screenshot

As you may know, Facebook has a chat service. For me at least is slowly becoming the place where I have more people talking to me, and as you may also guess, the value of social systems is very tied to the number of users.

Sadly, Facebook guys where not smart enough as the Google guys and brought yet another damn protocol to this protocol overpopulated world. Then came the worst part. They announced something that was not there and promised Jabber support. One year later nothing has yet happened.

For a such popular service, one starts to think whether waiting another year is worth for a protocol that is so popular. As I wanted it myself now, at some point I decided I was willing to implement it even if a Jabber version was available later.

We already have the problem that users expect to see Google talk in the Kopete list, because developers don’t figure out that grandma does not know what Jabber/XMPP is. So a good improvement would be adding the concept of “services” where we could add a protocol by just saying “it is just jabber, but with this server settings, this logo and this name”. That path would allow for a easy move to other XMPP protocols later.

But for Facebook, no more wait. Yesterday I was able to use it for first time to chat, so I am blogging about it.

Next steps:

  • Add more error handling
  • Fix a bug in the contacts status when they go offline
  • Put it into kopete or playground svn
  • Make an openSUSE package ;-)
  • Cleanup. I started over the testbed plugin and it added some stuff that probably I don’t need
  • Proxy support. I coded the engine using QNetworkAccessManager so it is KDE independent. Only the Kopete plugin is KDE based, so I haven’t looked into proxy support and other stuff

Other stuff with less priority:

  • Adding contacts from the client
  • Configuration (there is no much to configure)
September 29, 2008

The natural order of things…

Polyglot programmers

In the book “The Productive Programmer”, written by Neal Ford, there is a nice chapter that talks about an old topic: languages, and defines Polyglot programming as the kind of tendency in the industry to manage the complexity of current applications.

It is tempting to think that one language keeps the complexity low, but that is exactly the reason why languages keep coming. They usually try to become general purpose languages and start to get bloated or inheriting nonsense stuff.

While thinking on this topic. I started to remember lot of episodes in my life as a software developer. Having learned lot of my base in the KDE community, I was quite natural to think in the way Neal explains. In KDE people write since the beginning of the platform a good bunch of the static user interface descriptions in domain specific languages, which are transformed to more general languages (C++) at compilation time.

The very basics of Qt is C++ plus a “platform” and some specific add ons (another domain specific language for component communication) which are compiled into support code at compilation time. Code generation using DSL’s goes beyond that: Configuration for applications can be specified in a simple XML schema for the configuration domain and most of the code is generated. Therefore consistent, robust and bug free. For a KDE guy, this sounds natural (however it could be extended much more), and all the platform is like the book “Ola’s Pyramid”, where the lower levels are done using general languages (like C) and upper layers are done using more domain specific languages. We miss the intermediate part of scripting languages, but I am sure Plasma will be the first component following that natural order of things.

At that time I was learning, and the KDE “way” became natural. At the same time, that was the time when I discarded the Gnome platform completely. Mostly because I heard lot of FUD against KDE decisions at that time, lot of attacks and ignores towards a more common world, and then the world kinda inverted itself and used to be criticized stuff like use of preprocessor to add features to the language (Qt’s moc) : Welcome Vala? or the ignored dcop bus : Enter dbus, Object orientation (try to enter GObject ugh)… are now part of the “natural order of things”. I was kind of confused ( famous hackers claiming they won’t program apps in C again, uh? ).

As a side note, some developers, like Cornelius Schumacher and André Duffeck played with this concept of generating code much further. Like mixing models and user interfaces.

polyglot YaST

As a YaST developer, I keep thinking in the current code base, the directions we are taking, etc. The development field is full of new silver bullets, languages and things that make hard to keep the big picture if you are following previously unknown fields.

Surprisingly YaST is a very good example in the whole model. We abstract the low level system with a C++ made platform, and run a domain specific language called YCP on top, and have another domain specific language to manage the system configuration. It is a very good example of a complex platform that manages complexity using different languages, and it is a very mature platform at the same time. Of course there are lot of things that can be improved:

  • No usage of convention over configuration: There is an abuse of “skeletons”, that is, generating trees and code, putting it into version control, instead of doing most things magically by convention. (Very similar to the difference of rails to Java use of XML).

  • Defining user interfaces using code is ok as long as the code is not where it should not be. And the code base has this problem. Having an external DSL for this helps forcing you to separate things.

  • Hard to bind to the platform: Writing components is boring and over engineered. It works for complex cases (like defining your own type of component functions), but fails for the simple case. Try doing a ruby extension. It is easy. I think this is something we should improve. There are some basic support like adding some type information (using a DSL) on the headers and parsing that.

  • We should check and recheck that we are not repeating ourselves. Duplicated functionality, declarations and implementations.

Code generation for services

Now that we are walking towards the world of services, Web and such, it is time for new ideas. It is interesting to see big players trying to solve difficult problems, and coming up with natural solutions, like the case of Google with their protocol buffers, and Facebook with Thrift (paper).

Thrift is more interesting, as it comes from the situation of having to develop different services that need to communicate without needing to care much about what was used to build that component (SOA approach, which is not very different to what we are solving with dcop-ng (aka dbus) in the desktop scenario), but imagine dbus is your network, and thrift is the Qt dbus binding generator or dbusxml2something.

Thrift is a software framework for scalable cross-language services development. It combines a powerful software stack with a code generation engine to build services that work efficiently and seamlessly between C++, Java, Python, PHP, and Ruby. Thrift was developed at Facebook and released as open source.

Thrift allows you to define data types and service interfaces in a simple definition file. Taking that file as input, the compiler generates code to be used to easily build RPC clients and servers that communicate seamlessly across programming languages.

Now that schubi has been doing quite progress on exposing some YaST functionality via http (result of the last workshop), I am really curious if we can define our platform, and tackle some problems by defining very domain specific tools that can save us from repetition. Will see.