Title: Architecture
Slug: architecture

The architecture of libpurple is a bit complicated as it has two major
abstractions. This is just a high level look at everything to get started.

We call libpurple `the core` as it abstracts the functionality of communication
platforms, which we call `protocols`, into an easy to use API. It also defines
a set of behaviors for `user interfaces` to make it easy to create custom user
interfaces.

# The core

In modern parlance, libpurple would be considered a "back end". It is typically
not seen by an end user but handles data and logic.

Libpurple has always aimed to be as highly customizable as possible. With
version 3 things have gotten a tad more strict but we strive to make it
possible to support anything that people want to implement from both the
`protocol` and `UI` abstractions.

Libpurple does not contain any user interface or protocol specific code. The
protocols that ship with libpurple are plugins and not part of the library
itself.

# Protocols

In modern parlance a protocol could be considered something like an external
service like E-Mail, File Storage, Databases, etc that libpurple (the backend)
uses for additional functionality.

As mentioned above, protocols are implemented via plugins and _should_ be able
to be written in any language that we have a plugin loader for. They can be
normal chat networks or something more exotic like an RSS Reader, micro
blogging service, and so on as long as it can fit into the abstractions.

Like libpurple, protocols are not allowed to have any `UI` code. Of course this
isn't enforced in any meaningful way, but by following this rule the protocols
will be available to any user interface built on top of libpurple.

# User Interfaces

User interfaces are the main software that people will be interacting with. In
modern parlance, the user interface would be considered a "front end".

Most people reading this are probably familiar with
[Pidgin](https://pidgin.im/) but there have been other user interfaces built on
top of libpurple like [Finch](https://finch.im/) and [Instant
Bird](http://instantbird.com/). Unfortunately both of those are more or less
defunct at the time of this writing.

There are other applications out there that interface with libpurple but don't
implement the user interface abstraction of libpurple. This would be software
like [Adium](https://adium.im/),
[bitlbee-libpurple](https://wiki.bitlbee.org/HowtoPurple),
[Meebo](https://en.wikipedia.org/wiki/Meebo), among others.

User interfaces should not have any need to interact directly with a `protocol`
as the `core` API should have everything that the `UI` needs to make everything
work but of course there are always exceptions to the rules.
