[Telepathy] Empathy FT backend

[Sjoerd Simons]

Hi,

  Some time ago i promised people to send out a mail on how the FT backend
  should be designed (and why the current version is wrong). Then vacation
  happened, but here is the promised mail after all :)

  Currently most things in empathy assume that a CM will return Channel quite
  quickly and that you don't really need to do any time-consuming work before
  requesting a channel. So for example opening a chat dialog from the user
  lists works like this:

  0: User double-clicks on the contact list
  1: A call to the dispatcher is made to request a text channel from the CM
  2: dbus traffic happens, text channel is returned
  3: the text channel gets dispatched
  4: Empathy pops up a chat dialog

  The obvious problem with this approach is that there is no feedback to the
  user between step 0 to 4 and maybe more importantly there is no way to do
  error feedback. (Part of the new dispatcher work was to provide the necessary
  API to make this actually possible though).

  Even with all it's downsides this approach works reasonably for text channels
  as the CM usually return those quite fast and they usually don't fail (and if
  they do it's mostly because the CM fell over completely)...

  It breaks down completely for FT because the client is expected to do some
  work before actually requesting the Channel. Which includes getting a whole
  bunch of info about the file, potentially include a hash (which can take
  quite a while on a bigger file). Another issue is that the dispatcher is the
  one with the knowledge about how to request channels, which is kinda
  unfortunate since requesting channels is becoming more complex.. So this
  needs some rethinking.

  What i've been doing for VOIP calls is to split up the responsibility into
  several objects:
    * channel wrapper: Same as exist now. Small wrapper providing a convience
      layer around a channel. Should be reasonably small and simple.
    * channel handler: One level higher. Among the things it does is being able
      to request channels and do the actual handling. In the VOIP case this is
      where the management of telepathy-farsight lives. For the FT case this
      should probably contain the code to actually send the file to the CM.
    * some bit of UI: Something to let the user interact with the handler :)

  And the last thing in the mix is a factory which you can either give a
  Channel (for an incoming channel) or some minimal information (in the VOIP
  call case a contact, for the FT case a contact and a GFile probably), which
  then creates a Handler object and signals this.

  What this all means is that there can be visible user feedback before any
  D-Bus call is made :) And also that there is a logical place to show
  feedbacks on errors.

  In the FT case sending a file would become something like:

  0: User selects a file
  1: Info gets passed to the FT handler factory
  2: A new handler is created this is signalled
  3: As a response to the signal a bit of UI pops up
  4: The UI calls _start on the handler
  5: Handler starts hashing the file, UI shows feedback on this ( % done etc)
  6: Handler request the FT channel etc etc..
  7: Profit!

  Again, this means that the user gets feedback from the start even if it's way
  before a channel ever gets requested :) The other huge benefit is that all
  the logic of preparing a request for specific channel is now in the Handler
  instead of in the dispatcher which can thus become simpler :)

  Sjoerd
-- 
When the weight of the paperwork equals the weight of the plane, the
plane will fly.
		-- Donald Douglas