Message Filtering Plugin System
Lasath Fernando
Short description: Create a completely asynchronous modular and extensible system that enriches messages before they're dispalyed to the user. These includes embedding images and videos from links, Translating messages, (re)-formatting them nicely, reading out loud etc.
Name: Lasath Fernando
Email Address: kde@lasath.org
Freenode IRC Nick: shocklateboy92
IM Service and Username:
Google Talk (Jabber) : shocklateboy92@gmail.com
Location (City, Country and/or Time Zone): Sydney, Australia (GMT+10)
Email Address: kde@lasath.org
Freenode IRC Nick: shocklateboy92
IM Service and Username:
Google Talk (Jabber) : shocklateboy92@gmail.com
Location (City, Country and/or Time Zone): Sydney, Australia (GMT+10)
Proposal Title: Message Filtering Plugin System
Motivation for Proposal / Goal:
Project Goals:
To have a functioning, dynamic set of plugins that process chat messages, and enrich them in some way before displaying them to the user. They will be shared between the KTp-Text-Ui and KTp-Chat-Plasmoid and KTp-Log-Viewer and be easily reusable by any future component that displays text.
These messages will be ‘enriched’ in the way of :
I plan to develop quite a bit during this project. I want to learn how to (and have experience) make an extensible framework based on plugins; I want to learn how to make efficient, intuitive asynchronous APIs as well is further improve my programming skills.
I also want to develop my Project Management Skills: While I’ve hacked on various projects in my spare time a lot, I don’t have experience working on a ‘project’ with clear set goals and a deadline.
However, the most significant factor in my motivation for doing GSoC was that I wanted to improve my time management skills. I feel don’t have experience effectively balancing my time between multiple commitments. I.e. I’ve never done more than one important thing at a time. I feel that juggling a full workload at university and doing summer of code will teach me valuable skills in managing my time.
The reason I chose KDE, was because it’s my primary DE (and has been for over 2 years). I felt I should start giving something back and started contributing a few months ago to KTp. The team has been absolutely awesome and I’ve gotten to know them quite well over this time. The reason I chose this project specifically was because I use KTp on a daily basis and II felt that its text-ui could offer more metadata and display its messages in a much richer form. This would not only make it more engaging to the user, but will give back its competitive edge over other IM clients.
To have a functioning, dynamic set of plugins that process chat messages, and enrich them in some way before displaying them to the user. They will be shared between the KTp-Text-Ui and KTp-Chat-Plasmoid and KTp-Log-Viewer and be easily reusable by any future component that displays text.
These messages will be ‘enriched’ in the way of :
- Web Integration
- Bookmarks - automatically make bookmarks of recieved links
- Image - embed previews of links to images in chat
- YouTube - embed or generate previews for youtube links in chat
- Bugzilla - (or other KDE specific stuff) show title and description of link to bug
- Wikipedia - Embed first paragraph (and image) from links to Wikipedia
- Description - Embed title and image (like facebook and google+ does when sharing) of an any incoming link.
- Mailto - Replace email addresses in messages with appropriate mailto: links.
- Accessibility
- Translator - translates incoming and outgoing messages to predefined languages
- Jouvie plugin - option to automatically read out messages
- Extensibility
- Pipes - pipe messages through external program
- Auto-Replace plugin - replace user defined keywords in messages
- Search Commands - replaces commands like ‘lmgtfy:dbus tubes’ with ‘http://lmgtfy.com/?q=dbus+tubes’ before sending.
- Enhanced Display
- Highlight - highlight messages based on criteria
- Latex - renders incoming latex in window
- GTalk Formatting - turn “_this_ -or- *this*” into “this or this”
I plan to develop quite a bit during this project. I want to learn how to (and have experience) make an extensible framework based on plugins; I want to learn how to make efficient, intuitive asynchronous APIs as well is further improve my programming skills.
I also want to develop my Project Management Skills: While I’ve hacked on various projects in my spare time a lot, I don’t have experience working on a ‘project’ with clear set goals and a deadline.
However, the most significant factor in my motivation for doing GSoC was that I wanted to improve my time management skills. I feel don’t have experience effectively balancing my time between multiple commitments. I.e. I’ve never done more than one important thing at a time. I feel that juggling a full workload at university and doing summer of code will teach me valuable skills in managing my time.
The reason I chose KDE, was because it’s my primary DE (and has been for over 2 years). I felt I should start giving something back and started contributing a few months ago to KTp. The team has been absolutely awesome and I’ve gotten to know them quite well over this time. The reason I chose this project specifically was because I use KTp on a daily basis and II felt that its text-ui could offer more metadata and display its messages in a much richer form. This would not only make it more engaging to the user, but will give back its competitive edge over other IM clients.
Implementation Details:
The implementation will be completely modular and extensible. It will consist of a series of plugins that are dynamically loaded at runtime and a message processor that manages (and executes) them.
Message Processor:
The groundwork for this has already been laid. In anticipation for this project, I took a look at Kopete’s code (as this project has been inspired by its features) and got a feel for how it’s implemented there.
I also created a small scale message processor to gauge the amount of work this would take (so I can make a more precise timeline). It currently manages a hardcoded list of ‘filters’ in much the same way that kopete does - once a message comes in (or goes out), it iterates through all of them and executes sequentially.
While this is works, it has the same fatal flaw that Kopete does - until all plugins have finished processing the message, it can’t be displayed to the user. So in effect, there could be a noticeable delay between the message arriving and it being displayed to the user.
I plan to fix this by making my solution completely asynchronous. That is, once a client gives a message to be processed, it will return immediately. There will be an asynchronous API that notifies the client as each plugin makes changes to the message, and eventually be marked as complete.
Plugins:
Unlike the hard-coded list of filters currently in message processor, the final solution will load all of them at run-time. KDE already provides a nice framework for this called KPluginLoader and I think it will be sufficient.
The plugin’s metadata file will contain if it should be used for incoming or outgoing messages (or both) as well the priority that will be used to determine its position in the que (to be executed). Plugins with the same priority will be executed together, while plugins with lower priority will wait till the higher priority plugins are complete.
There will be a KCM allowing the user to enable/disable any plugin, as well as exposing any options each plugin may have to the user.
Message Processor:
The groundwork for this has already been laid. In anticipation for this project, I took a look at Kopete’s code (as this project has been inspired by its features) and got a feel for how it’s implemented there.
I also created a small scale message processor to gauge the amount of work this would take (so I can make a more precise timeline). It currently manages a hardcoded list of ‘filters’ in much the same way that kopete does - once a message comes in (or goes out), it iterates through all of them and executes sequentially.
While this is works, it has the same fatal flaw that Kopete does - until all plugins have finished processing the message, it can’t be displayed to the user. So in effect, there could be a noticeable delay between the message arriving and it being displayed to the user.
I plan to fix this by making my solution completely asynchronous. That is, once a client gives a message to be processed, it will return immediately. There will be an asynchronous API that notifies the client as each plugin makes changes to the message, and eventually be marked as complete.
Plugins:
Unlike the hard-coded list of filters currently in message processor, the final solution will load all of them at run-time. KDE already provides a nice framework for this called KPluginLoader and I think it will be sufficient.
The plugin’s metadata file will contain if it should be used for incoming or outgoing messages (or both) as well the priority that will be used to determine its position in the que (to be executed). Plugins with the same priority will be executed together, while plugins with lower priority will wait till the higher priority plugins are complete.
There will be a KCM allowing the user to enable/disable any plugin, as well as exposing any options each plugin may have to the user.
Note: While making the small scale processor, I also made a prototype of the Image Plugin. Here is a screenshot:
Tentative Timeline (in weekly intervals until 2 weeks after the end of GSoC):
The timeline will be split into four key tasks:
- Rebuilding MessageProcessor (May 21 to Jun 10) -
ensuring this is functioning correctly is important, thus I’ll allocate 3 weeks for it - Implementing blocking versions of (most of) the plugins (Jun 11 to Jul 1) -
synchronous versions will be much easier to debug, and will allow me to solve all the issues with the more difficult plugins - Refactoring MessageProcessor API to be asynchronous (Jul 2 to Jul 22) -
I haven’t designed an asynchronous API before, but I’m certain my mentor has enough experience to help me get this done within 3 weeks. - Port existing plugins to new API and implement remaining ones (Jul 23 to Aug 12) -
this *should* be a fairly straightforward process. - Implement any plugins that couldn’t be implemented in time or haven’t been thought of yet (Aug 13 to ???)
Do you have other obligations from late May to early August?
I'm fairly certain I can balance university and summer of code workload. However, I have an exam block between 8th June to 25th June. During this time I will probably be able to continue working on my project, but at a reduced pace. This is why I allocated just implementing the asynchronous messageProcessor (which should take less work than
About Me (let us know who you are!):
I am a 19 year old full time student studying Software Engineering at the University of New South Wales in Sydney, Australia. I only started using Linux (and KDE) about 2 and a half years ago. About a year ago, I got in contact with the KTp developers and managed to submit my first patch to KDE (or any FLOSS project for that matter). From there on, I started to contribute more and more and last summer (December) I made the ktp-chat-plasmoid. I also came up with the idea that there should display content in a nicer way. The rest of the team refined this idea and made it into a summer of code project, and here I am. I also have a lot of experience working with teams on the other side of the world (and especially my would-be mentor).
I have a passion for learning (the primary reason I ever started contributing to open source I think), trying new things and am always looking to improve my skills.
I have a passion for learning (the primary reason I ever started contributing to open source I think), trying new things and am always looking to improve my skills.