Editing User:Jaffa/Hermes plugins

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

== Background ==
[http://hermes.garage.maemo.org/ Hermes] currently supports two services: Facebook and Twitter. However, there are patches for both Hyves<ref>[https://bugs.maemo.org/show_bug.cgi?id=6995 #6995] - Request for Hyves as a data source</ref> and Gravatar<ref>[https://bugs.maemo.org/show_bug.cgi?id=5983 #5983] - Pull down images from gravatar.com...</ref>, as well as requests for LinkedIn<ref>[https://bugs.maemo.org/show_bug.cgi?id=6990 #6990] - Request for LinkedIn as a data source</ref>, MySpace<ref>[https://bugs.maemo.org/show_bug.cgi?id=6994 #6994] - Request for MySpace as a data source</ref>, Plaxo<ref>[https://bugs.maemo.org/show_bug.cgi?id=6991 #6991] - Request for Plaxo as a data source</ref> and LiveJournal<ref>[https://bugs.maemo.org/show_bug.cgi?id=6992 #6992] - Request for LiveJournal as a data source</ref>. Further services will almost certainly be required.

The existing Hermes [https://garage.maemo.org/plugins/ggit/browse.php/?p=hermes source] is fairly geared towards Facebook and Twitter, and so there are both architectural and UI challenges in supporting many more services.

== Requirements ==
# Ability for the user to select which services to use and the priority of them<ref>[https://bugs.maemo.org/show_bug.cgi?id=6990#c4 #6990.c4], Fredrik Wendt</ref>
# Optional configuration screen for each service, e.g. authentication information
# UI shouldn't be overly generic to avoid same mistakes of Microfeed.

== UI design ==
* Change the "Accounts" dialogue to be like the sharing plugins: a list of icon-containing services which are enabled, with an "Add" button, a "Remove" button, "Move Up/Down" buttons and an "Edit" button which is enabled when an item is selected and further preferences are available.
* Each service needs to provide an interface for opening the preferences for it, if any. For Facebook this'd be "Create birthday-only contacts", an "Authorise"/"Deauthorise" button.

== Code design ==
''See early discussion on [https://bugs.maemo.org/show_bug.cgi?id=6990#c3 #6990].''

A <code>Friend</code> class would be introduced to give better defined access to name, service and picture. This is used in manual mapping, and for communication between the controller and the service. It would also store the contacts to which it was mapped, if any.

A root class provides meta-data about the service (such as name and icon) and access to the further UI configuration dialogue (if any) and the backend of the service.

The service backend will implement an interface based on a visitor pattern:

<syntaxhighlight lang=python>
  def get_friends(self):
    """Return a list of friends from this service, or 'None' if manual mapping
       is not supported."""

def process_contact(self, contact, overwrite = false, friend = None):
    """Called for each contact in the address book. Any friends linked to
       from the contact should have their matching updated. The backend should 
       enrich the contact with any meta-data it can; and return 'True' if any
       information was updated. If 'friend' is provided, the information should
       be retrieved from friend. This will be one of the entries from 
       'get_friends' when manual mapping is being done."""

def finalise(self, updated, overwrite = false):
    """Once all contacts have been processed, allows for any tidy-up/additional
       enrichment. If any contacts are updated at this stage, 'updated' should
       be added to."""
</syntaxhighlight>

The main engine, <code>Hermes</code>, would then do something like the following pseudo-code:

<syntaxhighlight lang=python>
  friends = ()
  for service in services:
    for friend in service.get_friends():
      friends.add(friend)

all_contacts = get_contacts_as_set()
  updated_contacts = set()
  for contact in all_contacts:
    for service in something.get_services_by_prioritisation():
      if service.process_contact(contact):
        updated_contacts.add(contact)
        save_contact(contact)
</syntaxhighlight>

Some kind of mapping to a dict would then be made of <code>friends</code> when showing the GUI.

=== Unanswered questions ===
* Should some <code>X-HERMES-...</code> fields be used to indicate what Hermes can overwrite<ref>[https://bugs.maemo.org/show_bug.cgi?id=5452 #5452] - Don't overwrite pre-existing contact info</ref>; if so, what if the user ''does'' want to overwrite some info? For matching, URLs should be sufficient for most services.

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Retrieved from "https://wiki.maemo.org/User:Jaffa/Hermes_plugins"

Personal tools

Navigation

Views

Editing User:Jaffa/Hermes plugins

@@ Line 12: / Line 12: @@
 * Change the "Accounts" dialogue to be like the sharing plugins: a list of icon-containing services which are enabled, with an "Add" button, a "Remove" button, "Move Up/Down" buttons and an "Edit" button which is enabled when an item is selected and further preferences are available.
 * Each service needs to provide an interface for opening the preferences for it, if any. For Facebook this'd be "Create birthday-only contacts", an "Authorise"/"Deauthorise" button.
-* The existing "Fetching friends' info" would be changed to a progress-bar: "Initialising services" with information on each service being initialised.
 == Code design ==
 ''See early discussion on [https://bugs.maemo.org/show_bug.cgi?id=6990#c3 #6990].''
-The existing code in <code>contacts.py</code> would be migrated into a <code>Contact</code> class. This would, in addition to providing access to the various fields of concern, cache the name variants and provide a method for checking matches:
-<syntaxhighlight lang=python>
-  def matches_identifier(id):
-    """Returns true if the Unicode-normalised, lower-case, non-alphabetic
-       stripped characters of 'id' matches a name variant of this contact.
-       Fields included in the name variants are:
-         * First name
-         * Last name
-         * Nickname
-         * Email address (with post-@ dot-suffices removed."""
-</syntaxhighlight>
 A <code>Friend</code> class would be introduced to give better defined access to name, service and picture. This is used in manual mapping, and for communication between the controller and the service. It would also store the contacts to which it was mapped, if any.
@@ Line 64: / Line 50: @@
    all_contacts = get_contacts_as_set()
-  contacts = set()
    updated_contacts = set()
-   for econtact in addressbook.get_all_contacts():
+   for contact in all_contacts:
-    contact = Contact(addressbook, econtact)
-    contacts.add(contact)
      for service in something.get_services_by_prioritisation():
        if service.process_contact(contact):
          updated_contacts.add(contact)
+        save_contact(contact)
-  for service in something.get_services_by_prioritisation():
-    service.finalise(updated_contacts)
-  for contact in updated_contacts:
-    contact.save()
 </syntaxhighlight>
@@ Line 84: / Line 62: @@
 === Unanswered questions ===
 * Should some <code>X-HERMES-...</code> fields be used to indicate what Hermes can overwrite<ref>[https://bugs.maemo.org/show_bug.cgi?id=5452 #5452] - Don't overwrite pre-existing contact info</ref>; if so, what if the user ''does'' want to overwrite some info? For matching, URLs should be sufficient for most services.
-* Should <code>process_contact</code> return a dict of updated fields? Then the engine can decide what to update based on prioritisation etc.
-* Do we need a collection of UI building blocks to help plugin developers create their dialogs in a consistent way? (Ralph)
-*:Such as 'browser-based authentication notification', username/password etc? Certainly wouldn't do any harm :-) --[[User:jaffa|Jaffa]] 11:56, 3 January 2010 (UTC)
-=== Notional implementations ===
-Services such as Facebook, Twitter, Hyves and LinkedIn would contact upstream during construction (similar to the existing model).
-Services such as Gravatar would contact upstream during finalisation, once the set of contacts with email addresses (and without photos if ''overwrite'' is false) has been identified.
-== References ==
 <references/>