Facebook in Pidgin

[Mark Doliner]

To hopefully wrap this thread up a little bit:

* We won't be adding a Facebook protocol plugin directly into
libpurple in the immediately future.  We can always revisit the
decision later.  The developers have spoken, and, unless Richard and
Sardul and others are strongly in favor of it, it sounds like the
majority of us developers are against it.

* Decisions about Pidgin and libpurple are made by the developers.
People who contribute more have more weight.  We very much appreciate
hearing users' opinions on everything, and in the end we make the
decision that we feel is best for Pidgin in the long run.

* Eion gave me commit access to his repository, so we'll work together
to improve the third party plugin.

* To discard something because it's time wasting is foolish.  People
like to waste time.  People like Facebook.  People like Facebook IM.
Pidgin is not strictly a business tool.

* Describing the prpl as "screen scraping" isn't entirely accurate.
While periphery actions (get info, add buddy) are implemented by
screen scraping, core actions (checking for incoming messages, sending
outgoing messages, getting your buddy list) are done by making an HTTP
POST request to a certain URL.  The response is JSON formatted.  If
there are no new messages waiting when the HTTP request is made then
the server will hold the connection open for a minute.  This is often
referred to as "long polling" or "comet."  It's a method of polling
that allows for the server to send data down to the client as soon as
possible.  Advantages of this approach are that traffic goes over port
80, and can easily be proxied.  It's also less likely to be blocked by
heavy handed corporate or school firewalls.  My main point is that
their protocol isn't an ugly hack.  It's reasonably well engineered.
Adding support for it by capturing and analyzing network traffic is
not much more ghetto than when we do this for AIM, MSN and Yahoo.

-Mark