Adium

Contact list import/export

There is currently no ContactList importer or exporter in Adium. For now, this wiki page is for the developers to plan this feature; when it's implemented, this will metamorphose into the help page for it.

Note that probably, not all of the features listed here will be implemented. We're brainstorming, and this page exists for the sole purpose of writing everything down. Don't get your hopes up that we'll actually do something that's on this list simply because it's on this list; we may decide not to do it, and if so, we'll probably list our reason here. This also means that you shouldn't cite this page in a ticket comment as evidence that we intended to do something; all it means is that we thought of it at some point or somebody we know suggested it at some point.

Necessary elements

  • A format for exported CLs
  • User interface for import
  • User interface for export
  • Back-end support for import (probably in Adium.framework, with support from the Adium libpurple plug-in)
  • Back-end support for export (probably in Adium.framework)

Format

First, we must pick a metaformat to build the format on:

  • Property list
  • Core Data
  • NSKeyedArchiver
  • Custom XML
  • Custom JSON
  • Custom binary
  • Your Metaformat Here

Then, we must decide how to arrange the data:

  • Single-account or multi-account?
    • A single account would just be a list of groups/contacts; no account information needed
    • Multi-account options:
      • (A) Array of accounts, each an array of groups, each an array of contacts
      • (B) Same group/contact arrangement as single-account format, but each contact would have an added property which would be a list of accounts on whose lists the contact was on
        • Side benefit: Could be the same as a single-account format
    • Either multi-account format would be better for backup purposes
    • The single-account format would be better for exchange of contacts (e.g., a corporation issuing a standard list of contacts that all employees should import)
  • Groups
  • Basic metadata for a contact:
    • Service
    • Username
    • Anything else?
  • Optional metadata for a contact:
    • Alias
    • Notes
    • Event overrides
  • Metacontacts
    • Contact controller redesign could make this much simpler (or not)

User interface

Import

  • List of checkboxes, one per account to import to
    • A single-account file would simply be cross-posted to every account
  • For a multi-account file (esp. format B), a checkbox controlling whether to consider account information in the file, or just import all contacts to every account
  • Radio buttons: For contacts with the same alias,
    • Combine them
    • Leave them separate
    • Ask me (the user)
  • Preview of changes that will be made
    • Added contacts/metacontacts
    • Updated metacontacts (e.g., new usernames)
  • Source:
    • File (with file-chooser control)
    • MobileMe (formerly known as .Mac)
    • WebDAV server
      • Field for nodename thereof

Export

  • List of checkboxes, one per account to export from
    • Obviously not needed if our file format only supports one account per file
  • Radio buttons:
    • Only export selected contacts that are on these accounts
    • All contacts on these accounts
  • A control to select a single-account file or a multi-account file (if we decide to have both kinds of format)
    • Wording would be tricky; “Include account information” sounds like a marketing “Do you want us to contact you?” type of question, even though it only means “Generate a multi-account file rather than a single-account file”
  • Destination:
    • File (with file-chooser control)
    • MobileMe (formerly known as .Mac)
    • WebDAV server
      • Field for nodename thereof
Page last modified by Robby, 4 years ago