User:Jaffa/Hermes plugins - Revision history

imported_>jaffa: /* Unanswered questions */ UI building blocks

2010-01-03T11:56:12Z

Unanswered questions: UI building blocks

← Older revision		Revision as of 11:56, 3 January 2010
Line 86:		Line 86:
	* Should <code>process_contact</code> return a dict of updated fields? Then the engine can decide what to update based on prioritisation etc.		* 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)		* 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 ===		=== Notional implementations ===

195.241.8.37: /* Unanswered questions */

2010-01-03T10:46:45Z

Unanswered questions

← Older revision		Revision as of 10:46, 3 January 2010
Line 85:		Line 85:
	* 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 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.		* 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)

	=== Notional implementations ===		=== Notional implementations ===

imported_>jaffa: Further clarification after more discussion with ceda

2010-01-02T09:52:33Z

Further clarification after more discussion with ceda

← Older revision		Revision as of 09:52, 2 January 2010
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.		* 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.		* 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 ==		== Code design ==
	''See early discussion on [https://bugs.maemo.org/show_bug.cgi?id=6990#c3 #6990].''		''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.		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 50:		Line 64:

	all_contacts = get_contacts_as_set()		all_contacts = get_contacts_as_set()
			contacts = set()
	updated_contacts = set()		updated_contacts = set()
	for ~~contact~~ in ~~all_contacts~~:		for econtact in addressbook.get_all_contacts():
			contact = Contact(addressbook, econtact)
			contacts.add(contact)
	for service in something.get_services_by_prioritisation():		for service in something.get_services_by_prioritisation():
	if service.process_contact(contact):		if service.process_contact(contact):
	updated_contacts.add(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>		</syntaxhighlight>

Line 62:		Line 84:
	=== Unanswered questions ===		=== 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 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.

			=== 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 ==
	<references/>		<references/>

imported_>jaffa: Add references title.

2010-01-01T11:14:21Z

Add references title.

← Older revision		Revision as of 11:14, 1 January 2010
Line 63:		Line 63:
	* 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 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.

			== References ==
	<references/>		<references/>

imported_>jaffa: Fixes with suggestions from ceda

2010-01-01T11:12:39Z

Fixes with suggestions from ceda

← Older revision		Revision as of 11:12, 1 January 2010
Line 44:		Line 44:

	<syntaxhighlight lang=python>		<syntaxhighlight lang=python>
	friends = {}		friends = ()
	for service in services:		for service in services:
	for friend in service.get_friends():		for friend in service.get_friends():
Line 57:		Line 57:
	save_contact(contact)		save_contact(contact)
	</syntaxhighlight>		</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.

	<references/>		<references/>

imported_>jaffa: Design of pluggable Hermes infrastructure

2010-01-01T11:00:07Z

Design of pluggable Hermes infrastructure

New page

== 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>

<references/>