1. 06 Sep, 2012 3 commits
  2. 05 Sep, 2012 5 commits
  3. 28 Aug, 2012 2 commits
    • Philip Withnall's avatar
      Bug 682719 — eds test fails to compile · 2dcbc92f
      Philip Withnall authored
      Don’t use deprecated EDS API in the EDS tests. The replacement API doesn’t
      require a dependency version bump.
      
      Closes: https://bugzilla.gnome.org/show_bug.cgi?id=682719
      2dcbc92f
    • Philip Withnall's avatar
      core: Support lazy initialisation of properties · 4a59af5c
      Philip Withnall authored
      Creating several HashSets and HashMultiMaps for every Individual turns
      out to be quite wasteful, especially when most of them will typically be
      empty (as address books are generally quite sparse on properties) and never
      accessed (since most clients don’t need local IDs or web service addresses).
      
      This commit delays initialisation of various multi-valued Individual
      properties to the first time they’re accessed, giving them a null value
      before that time. It preserves the existing API for Individual, i.e. the
      properties themselves remain non-nullable, and only the object members
      backing them become nullable.
      
      This does introduce a slight behaviour change, in that an Individual will
      now emit change notifications for a non-initialised multi-valued property if
      *any* of the Personas in the Individual emit a notification for that
      property. This is because the Individual can’t compare the current value of
      its property to the new one resulting from the change in the Persona’s
      property value to determine if a change has really occurred. Therefore the
      Individual makes a safe over-estimate and emits notifications which might
      be false positives.
      
      This shouldn’t be a problem: if a client is interested in the property,
      they will have already queried it and caused it to be initialised.
      Initialised properties have the same notification behaviour as before.
      If a client isn’t interested in the property, it won’t be connected to the
      property notifications anyway.
      
      This change roughly quarters the number of GObjects being created when
      opening folks-inspect with the Telepathy, key-file and EDS backends enabled
      and ~115 personas in the system.
      4a59af5c
  4. 25 Aug, 2012 1 commit
  5. 23 Aug, 2012 1 commit
  6. 16 Aug, 2012 1 commit
  7. 15 Aug, 2012 1 commit
  8. 10 Aug, 2012 1 commit
  9. 31 Jul, 2012 1 commit
  10. 29 Jul, 2012 1 commit
  11. 23 Jul, 2012 2 commits
  12. 19 Jul, 2012 1 commit
    • Philip Withnall's avatar
      telepathy: Allow for updated Tpf.Personas properties to update the cache · 36ecd01a
      Philip Withnall authored
      Currently, the cache is only written when going offline, which means that any
      properties of Tpf.Personas which are updated at runtime aren’t written to the
      cache unless the client explicitly goes offline before being closed. This
      doesn’t often happen, meaning the property updates are lost and the cache
      becomes stale.
      
      This commit keeps track of the clean/dirty state of the cache and writes it
      out when PersonaStore.flush() is called. It also adds a new method,
      IndividualAggregator.unprepare(), which ensures all the persona stores handled
      by the aggregator are flushed. Clients should call this method before closing
      their main loop.
      
      (Calling flush() in the finalise function of the PersonaStore doesn’t work
      because Tpf.PersonaStores are often never finalised due to the implementation
      of Tpf.PersonaStore.dup_for_account(). Furthermore, calling flush() in the
      finalise function of the IndividualAggregator doesn’t work because the client
      will typically quit the main loop immediately afterwards, which will cancel
      the asynchronous flush call.)
      
      New API:
       • IndividualAggregator.unprepare()
      
      Helps: https://bugzilla.gnome.org/show_bug.cgi?id=660128
      36ecd01a
  13. 18 Jul, 2012 1 commit
  14. 16 Jul, 2012 1 commit
  15. 13 Jul, 2012 1 commit
  16. 11 Jul, 2012 1 commit
  17. 07 Jul, 2012 1 commit
    • Philip Withnall's avatar
      core: Add core anti-linking support · 1441ae9d
      Philip Withnall authored
      This adds the core of the anti-linking support, based around a new
      AntiLinkable interface. This will be implemented by Persona subclasses which
      can store anti-linking information (in the form of a set of Persona UIDs
      which the given Persona should never be linked to).
      
      This approach allows anti-linking information to be stored with the personas
      (presumably in the primary persona store) and thus it should be network
      transparent. i.e. Using folks on two different computers with a Google
      Contacts address book as primary should cause the anti-linking data to be
      shared.
      
      This also includes the necessary IndividualAggregator changes.
      
      Sadly, no unit tests are included.
      
      Closes: https://bugzilla.gnome.org/show_bug.cgi?id=629537
      1441ae9d
  18. 06 Jul, 2012 1 commit
  19. 03 Jul, 2012 1 commit
  20. 28 Jun, 2012 4 commits
  21. 27 Jun, 2012 1 commit
  22. 25 Jun, 2012 3 commits
  23. 18 Jun, 2012 1 commit
    • Philip Withnall's avatar
      Bug 677166 — Salut personas survive disconnection · c8fa98d3
      Philip Withnall authored
      Handle TpAccounts being disabled by listening for
      TpAccountManager::account-disabled rather than (erroneously) assuming that
      TpAccount:enabled will have been changed by the time the corresponding
      TpConnection is disconnected.
      
      This fixes a race condition when accounts are disabled, where the account’s
      personas would persist if TpAccount:enabled hadn’t changed by the time the
      connection was disconnected.
      
      This comes at the cost of potentially storing and re-loading the set of
      personas for that account to the cache, only to later delete the cache file
      when TpAccount:enabled changes. I can’t think of a simple fix for this.
      
      Closes: https://bugzilla.gnome.org/show_bug.cgi?id=677166
      c8fa98d3
  24. 15 Jun, 2012 1 commit
  25. 14 Jun, 2012 3 commits