GSOC Chat log storage: My thoughts

[Tomasz Wasilczyk]

2013/4/25 Ka-Hing Cheung <khc at hxbc.us>:
> On Sat, 2013-04-20 at 05:51 +1000, Peter Lawler wrote:
>> To my mind, a Chat Log storage format update would abstract out the
>> storage medium for the log. This would mean SQLite, MySQL, Postgres,
>> SMTP, SNMP, FTP, WebDAV, JSON, CSV or flat file logging 'plugins' would
>> be able to be written by anyone else. Naturally, taking this approach, a
>> GSOC2013 project would supply at least one of these backend plugins as
>> proof that it's working. This would keep with the general
>> pidgin/libpurple philosophy of abstraction and extensibility.
>
> One idea I've had is to interoperate with gtalk's IMAP chat log, so the
> logging side would be no-op and viewing would fetch from the IMAP server
> (and possibly cache locally). Ideally if you use a non-gtalk account,
> you would be able provide your own IMAP server and logs would be stored
> there. Searching would be done on the server side.
>
> If the pidgin crew agrees, I am willing to come out of retirement to
> mentor this given a good application. A good applicant should:
>
> 1) demonstrate that they have done research on what's necessary to bring
> the remote logging branch to main
> 2) demonstrate that they have thought about some of the problems of
> storing logs on an IMAP server
> 3) demonstrate that they can code by providing a sample program that
> connects to an IMAP server and list some emails.

I think, that your idea fits better into "XMPP prpl improvements"
project. Most users won't setup its own IMAP server for logs, so -
generally - the main beneficent will be xmpp-gtalk prpl user.
Unfortunately, this may depend on the result of this project, so it
may not be doable within another gsoc project this year.

IMAP storage can be implemented as another backend, but I prefer not
to mark this as /required/ part of project. Anyway, it would be
desired, because it would enforce good API, good enough for remote
logging. But not the most important part.

I have some objections to your good-applicant-requirements:

1) After a glance, I see remote logging branch relies on mysql
storage. I don't think this should be the /important/ part of project,
because its harder to setup mysql database than - let's say - IMAP
capable account. But looking into this branch could provide some
useful ideas, not necessarily by merging it at first.

2) I can think of four: all data like message time or related account
have to be de-serializable; stored logs should be readable by common
mail reader; we should be aware, that stored messages can be somehow
altered (by mail hosting or user); all additional data, like inline
images, also have to be stored.

3) As I raised above, IMAP storage shouldn't be the most important
part of this project, so I think that students can prove their coding
skills in other way. But that's general recommendation for all gsoc
projects: any contribution to Pidgin/libpurple would be nice
demonstration, links to other open source projects are also fine.

Again: I wouldn't take this as must-have, but it still should be
considered as one of (high priority) bonus tasks.

Tomek