@@ -32,35 +31,12 @@ *
* 1) The MetaContactListService is started.
* 2) If no file exists for the meta contact list, create one.
- * 2) We fill in the Contact list from what we have in the local file, by first
- * creating empty MetaContact instances (with no proto
- * Contact).
- * 3) paralelno s loadvaneto se syzdava index koito mapva
- * contactaddress:accountid na meta contact
- * 4) We receive an OSGI event telling us that a new ProtocolProviderService
- * or we simply retrieve one that was in the bundle context, before us. This
- * This gives us two possible cases:
- * A) The newly registered PP supports persistent presence (has
- * OperationSetPersistentPresence).
- *
- * - In this case all Contact instances retrieved from the protocol
- * provider are first being matched to all existing meta contacts, looking
- * for one that already contained the contact in question and we add it
- * into it. If the contact is a new on, we simply create a new MetaContact
- * to encapsulate it.
- * B) The newly registered PP does NOT support persistent presence.
- * - If this is the case, then we simply go through all contacts that have
- * been registered for this provider and create subscriptions for every
- * one of them.
- *
- * After completing the above procedure we would have two kinds of contacts that
- * remain unresolved.
- * 1) contacts whose corresponding provider was not found.
- * 2) Those who first originated out of a persistent operation set but were not
- * resolved during this run.
+ * 3) We receive an OSGI event telling us that a new ProtocolProviderService
+ * is registered or we simply retrieve one that was already in the bundle
+ * 4) We look through the contact list file and load groups and contacts
+ * belonging to this new provider. Unresolved proto groups and contacts
+ * will be created for every one of them.
*
- * @todo We should most probably delete the first and ask the user what to do - * with the second type. * * @author Emil Ivov */