GSoC Proposal First Draft

[Lasath Fernando]

Hi everyone,

Some of you guys already know I want to do GSoC this year, and that I
was going to use the idea that I came up with during woshibon of a
plugin system that changed / added metadata to incoming messages. To
the people that don't, well now you know.

Here's an early version of my draft proposal. I don't have a copy of
the official template I'm supposed to use, so I started putting things
together that I might need to mention in the final copy. But I decided
I'd like to get some feedback before I proceed any further.

If I've forgotten to add something here, or added stuff that's
unnecessary, do let me know.

Project Goals:
To have a functioning, dynamic set of plugins that process
incoming/outgoing messages, and enrich them in some way before
displaying them to the user. They will be shared between the
KTp-Text-Ui, KTp-Chat-Plasmoid, KTp-Log-Viewer and be easily reusable
by any future component that displays messages.

*Auto-Replace plugin - replace user defined keywords in messages
*Bookmarks - make bookmarks of recieved links
*Latex - renders incoming latex in window (will need to look at how
kopete did this)
*Translator - translates incoming/outgoing messages to predefined languages
*Pipes - pipe messages through external program
*GTalk Formatting - turn “_this_ -or- *this*” into “this or this”
*Image - make 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.
*Highlight - highlight messages based on criteria
*Search Commands - replaces commands like ‘gg:chuck norris’ with
‘http://www.google.com/search?q=chuck+norris&ie=UTF-8&oe=UTF-8’ before
sending.


Implementation:
The groundwork for this is already sort of laid. A little while ago, I
created a MessageProcessor class and two plugins to gauge how feasible
this project would be.

The MessageProcessor is currently synchronous, and simply iterates
through a list of hardcoded ‘Filters’ executing them one by one. Once
all processing is complete, it returns the message to the client which
can then display it to the user.

By the end of this project, the MessageProcessor will be almost
completely re-written. It will use KPluginLoader to load its filters
at runtime. Each plugin will have a priority associated with it that
the processor will use to determine the order it gets executed in.

When a message arrives the client passes it to MessageProcessor to
process, it will return straight away. Then using a completely
asynchronous API, it will inform the client of the message being
updated as each plugin finishes processing. The plugins will then have
the ability to communicate with external servers, or do any other time
consuming processing and update the message.


Timeline:
Um.. yeah. I’ll figure out how exactly I’m going to hack the space
time continuum and detail it here in my next draft.

-- 
Cheers,
Lasath