Skip to content
Back to top
View this page
Edit this page

# General Design

The main slidge entrypoint will automatically detect which classes have been subclassed and use them automagically. Just subclass away, and launch your legacy module with `slidge --legacy-module=your.importable.legacy_module`.

At the very minimum, you will need to subclass `BaseGateway` and `BaseSession` for a legacy module to be functional.

## JID local parts to legacy IDs

You probably also want to subclass `LegacyRoster` and `LegacyBookmarks` to define how JID local parts map to legacy user or contact IDs. Defining which local parts map to proper valid user legacy IDs is crucial to discriminate between JIDs that map to a `LegacyContact` and those that map to a `LegacyMUC`. You should override `jid_username_to_legacy_id()`, `legacy_id_to_jid_username()`, `jid_username_to_legacy_id()`, and `legacy_id_to_jid_username()` in your custom `LegacyRoster` and `LegacyBookmarks` classes, and raise an appropriate `XMPPError` when called with an invalid argument.

## Fetching info from the legacy service

By subclassing `LegacyContact` and `LegacyMUC`, you will be able to define how XMPP Entities update information about themselves, such as their user-facing name and the Avatar that represents them. This is done by overriding `slidge.contact.LegacyContact.update_info()` and `slidge.group.LegacyMUC.update_info()`, in which you should raise an `XMPPError` in case their `legacy_id` attribute is not valid.

## Pre-filling contacts and groups

The coroutines `slidge.contact.LegacyRoster.fill()` and `slidge.group.LegacyBookmarks.fill()` will be awaited just after `login()` and should be used to pre-fill known “friends” and groups.