Fwd: GSOC: Chat Log

Nathan Loewen loewen.nathan at gmail.com
Wed Apr 17 15:21:18 EDT 2013

> Doing everything in UI would be the easiest (and dirty) way to do this

Which would cheat you of good code, and me of a good learning experience :P
Lets do things the right way.

> However, the UI have to be totally unaware of underlying database (for
> example, to make it possible switching to something else in the
> future). This approach also reduces code complexity and makes things
> better considered. That's why I believe, this project is way harder
> than it looks like and it's easy to screw it up. Here are some of
> difficulties:
> - frontend and backend totally splitted, connected via *external* API
> - all routines should be (have to be?) asynchronous

I'm not sure how to write asynchronous code. Does it make sense to do the
database queries in its own thread and send the gtk window a signal when
the operation is completed? I'll need help here.
I took a look at Nader's asynclogging branch, but I'm not sure how useful
it is if we are reworking the API and using SQLite calls instead of writing
data ourselves. Nader, if you have some time to better explain it, please
ping me on irc. I've been lurking as "nloewen".

> - avoiding huge API - for example: conversation context should
> probably use the same routines that log viewer uses
> - long-lasting operations should provide a method to track them on
progress bar
> - figuring out good way to maintain inline images (this can be tricky
> and may require devastating half of current API) -> remember, that
> such messages will re-appear as conversation context on next Pidgin
> start

If we store an image ID inline and store the image
separately, reassembling it when the frontend asks for the message? I'm not
sure where to look to find how this is done now.

> - thinking forward: making it possible to use external log, or even
> implement it (as a plugin?)

I'd like to stay focused on getting a well written backend, and a frontend
that makes use of the new features. Having a well defined API for accessing
the log should make this easier in the future.

> I hope, this project will be fulfilled honestly, because these
> features are the ones which I mostly wait for.
> Tomek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20130417/109bf7f5/attachment-0002.html>

More information about the Devel mailing list