Difference between revisions of "Psi Plugins Soc 2006"
(Next update) |
m (→Plugin Ideas: remember to preview before you save.) |
||
Line 104: | Line 104: | ||
** This one's pretty crucial to the project | ** This one's pretty crucial to the project | ||
* URL watcher | * URL watcher | ||
** As [http://missig.org/julian/blog/2006/05/29/idea-im-link-history/ | ** As [http://missig.org/julian/blog/2006/05/29/idea-im-link-history/ Julian suggested], it would be nice for clients to keep a log of URLs sent to you which you can visit later, much like many IRC users enjoy. | ||
===Script Ideas=== | ===Script Ideas=== |
Revision as of 22:39, 30 May 2006
I am Kevin Smith (User:kevin) and this page details my plugin/scripting in Psi project for Summer of Code 2006; here are the other students' projects.
Overview
The aim of this project is to provide both a plugin system and, as a plugin, a Python scripting interface.
Progress
Week 1 (24th-31st May)
Initial work such as creating a branch of the Psi mainline repository completed.
Finding and displaying plugins
- I've implemented some (very basic and initial) code to locate installed plugins and to list them, together with their names (the plugins define their own names) in a new options dialog pane.
- Directory watching has been implemented on the plugin directories, such that new plugins will be located as soon as they're installed
- I've written plugin loading and unloading code. On Windows and Linux this means that plugins can be loaded and unloaded on the fly (allowing plugin upgrading while Psi is running). On OSX it's not possible to unload the .dylib once it's loaded and the code works around this, allowing plugins to be disabled but not unloaded, with the objects cached so they can be re-enabled later without a restart.
- I've written a large chunk of a generic (non-Psi dependent) soft-coded options structure. What this means is that you can use options dynamically by just calling something like
options.setOption("path.to.option",true)
and the value will be stored in the tree, regardless of whether the options tree was expecting you to have an option named "path.to.option" or not. This is then dumped to xml for storage on disc, and the xml parsed back in to recreate the tree. It's also possible to store comments for each node or value, this is useful both for the xml to be readable and for writing a generic options dialog, which allows you to edit any value stored in the tree, without knowing in advance what these are.
Tasks
This is as much a reference for myself as it is for anyone else; not all of the following tasks are necessary for the success of this project.
Plugins
Task | Completion |
---|---|
Locate plugins | Yes |
Load plugins and query for name | Yes |
Save enable/disable settings | 0% |
Allow plugin disabling | 50% |
Work around OSX not allowing plugin unloading | Yes |
Use DirWatch to find new plugins | Yes |
Display plugin's own options in OptionDlg | 20% |
Write a soft-coded options structure, such that we don't need to know what options we have in advance (and also allow us to remember options we don't know about, such as when running without plugins) | 75% |
Allow plugins to store their options in PluginManager (options[], with an options.addComment()) | 0% |
Allow plugins to define new Caps | 0% |
Define preliminary interface alerting plugins to messages, presence, iq | 5% |
Define an interface allowing plugins to modify or discard completely incoming and outgoing stanzas | 0% |
Allow plugins to register a namespace to listen to (or many namespaces) | 0% |
Allow the plugins to modify the GUI in some way (adding options to the right-click menu on the roster, for example). | 0% |
Python Scripting
Task | Completion |
---|---|
Create a simple plugin which loads the Python interpreter (Hello World) | 50% |
Develop a framework for locating scripts for Psi | 0% |
Choose scripts to load/not | 0% |
Develop a method for loading and executing scripts | 0% |
Write a glue layer from the plugin interface to Python | 0% |
Write a set of GUI glues, such that scripts can create message boxes and the like | 0% |
Plugin Ideas
This is just a list of plugins I might implement to showcase the interface if I have time.
- Null Plugin
- This is just to demo the plugin loading and does nothing (Complete)
- Hello World
- A simple plugin to pop up a "Hello World" dialogue at inopportune moments
- Console Dump
- Dump all incoming messages to console
- Python Scripting Plugin
- This one's pretty crucial to the project
- URL watcher
- As Julian suggested, it would be nice for clients to keep a log of URLs sent to you which you can visit later, much like many IRC users enjoy.
Script Ideas
- Console Dump
- Just as with the plugin, dump messages to the console
- Google New Mail
- Google Talk sends new mail stanzas, notify the user when they have new mail
The original proposal
Plugin and scripting support for rapid protocol prototyping in Psi
Project
Psi is a featureful, cross-platform Jabber client written in C++ using the Qt toolkit. Psi's traditional development cycle has focused on producing a stable, responsive client, and many users choose it for this reason. This thorough approach, however, coupled with the compiled nature of C++/Qt makes it difficult for users to customise their client. A C++/Qt plugin interface would allow users to share modifications and customisations without a need to either patch their builds, or to submit to the patch review process. Previous investigation has resulted in the beginnings of a plugin loader, but no plugin interface. The first section of this project proposal is to merge the previous plugin work into the current mainline and to write an abstraction interface, such that plugins need not access Psi's internals. It is expected that the first half of the project time would be spent on this, with priority on protocol abstraction in the interface rather than gui modification. If this work were to be completed early, there is the possibility to work on a configuration interface using Jabber data forms.
The second half of the project time would be spent on the development of a Python plugin, and the associated scripting interface. A scripting interface using a popular, high-level, easy to read/write language such as Python provides two very useful features. The first and potentially most obvious of these is that it allows users to add features to the client with use of nothing more than a text editor. The less obvious advantage is that it allows the Psi developers and JEP authors to rapidly prototype new features. The final days of the project would be spent, depending upon the time constraints, developing example scripts.
Plugin and scripting support are very frequently requested features for Psi so this would be a project benefitting many users and coupled with the ability to prototype protocol extensions easily would be a valuable contribution to the Jabber community in general, where multiple protocol implementations are important.
Me
I'm a 24 year old PhD Student studying Multi-objective optimisation techniques using simulated annealing algorithms in the Computer Science department of Exeter University (UK). I hold a BSc(Hons) degree in Computer Science from the University of Exeter, with first class honours. I received 'best results' awards in both my first and second years of my degree, and a first class grade my final-year project, which studied parallel implementations of multi-objective genetic algorithms with the focus on increased autonomy of nodes (allowing each machine to optimise a subset of the search space), written in C++. Degree modules relevant to a Summer of Code placement include a study of HCI, object-oriented programming in Java, GUI design, compiler creation, other languages such as LISP and assembly, system design, formal modelling and logic.
I have previously been a developer for two OSS projects, a psuedo-AI chatbot script (http://bmotion.sf.net) and the Psi Jabber client (http://psi-im.org). I've been contributing to Psi for approximately four years and have more recently been managing the project; as such I have a reasonable understanding of the issues involved in this project (and the Psi codebase) and am confident a solution can be produced in the timeframe. I am currently at the write-up stage of my thesis, aiming to be splitting my time between that and SoC for the start of June and thereafter dedicating it to SoC. This is the only SoC project I have applied for and I've not previously participated in the program.