Open UNIX Socket (TCP? Access control....)
Need communication protocol for CORE to UIs
Handles everything except for display:
Global preferences (users, back from away, anything non-UI related)
Loading/Unloading UI-independent plugins
Sounds? I don't know. This is kinda iffy. A GTK plugin might feel more at home with
ESD but a Qt plugin might prefer aRts.... Tough call. Maybe part of UI-C
protocol to play sound? That seems best.
Allows for multiple UIs. Each one is broadcast events. All are told exactly what to display
Can run without UIs at all (events will be queued until a UI is available again)
* need to consider downsides of this, and alternatives:
detach & persist (core still running but UI gone)
detach & resign (core and all UIs exit)
Always broadcasts all messages - every UI is the main UI
* May need to rethink this for error dialogs - don't want 100 dialogs on every UI
* Do we need to worry about synchronization? My guess is no: the CORE will only process one
message from any of the UIs or servers at a time.
PRPLs must be made mostly UI-independent.
Things which cannot be made protocol-independent must either be abstracted, or must
have "clues" sent to the UIs
Only tell CORE what user wants
Never assume they are to display anything on their own. (Sending a message will first be
cleared by the CORE, and then displayed by each UI. That way each UI has the same
display of the conversations that have happened. Then you can change location (via
ssh, e.g.) and have the console and GUI at home display the same thing.)
UI needs some way of notifying CORE of events, and vice versa.
XML? Messages will happen often, so parsing may be costly (then again, it's an IM client,
not a data processor, it doesn't need to be zippy)
Need messages for every function in struct prpl that takes a gaim_connection, as well as
every serv_ function that the prpls call.
Need ways of indicating arguments, variant arguments, etc. Per-message or each message has
Buddy state (online, offline, away, etc, etc.)
Messages (chat, IM, send, receive, etc.)
When new UIs are attached, they'll need to know basic information:
Buddy Lists for all online accounts
State for each Buddy List for each online account
* Should we keep track of the last few messages, so that when a new UI
attaches it knows where it is in the conversation?
