GSOC Chat log storage: My thoughts

[Tomasz Wasilczyk]

2013/4/25 Ethan Blanton <elb at pidgin.im>:
> Tomasz Wasilczyk spake unto us the following wisdom:
>> > 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.
>>
>> 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.
>
> So what if its primary beneficiaries are Google Talk users?  I think
> this project is both reasonable and useful.  You are probably correct
> that we could not take both a general logging project *and* this
> project in the same summer, due to conflicts and/or dependencies, but
> if we got the better application for this project, I wouldn't say that
> should stop it.

I just meant, that it fits better into xmpp project. Its definitely
useful and reasonable. I also think, the only fine solution to take
both ideas, it to get it bundled within one gsoc project.

As I said before, implementing IMAP backend can be a good idea to make
sure that new logging api will be remote-friendly.

> Having an experienced mentor willing to devote time to it is a big
> bonus, and not to be overlooked.

Yep, I wish my comments wouldn't sound so rough. I'm just concerned
about this project idea.

>> I have some objections to your good-applicant-requirements:
>
> I don't think you get to have these objections.  ;-)  I mean, you can
> have them, but they're not relevant.  If those are Ka-Hing's
> requirements, they're his requirements.
>
> In general, I think we should consider weighting similar requirements
> heavily.  Providing working code, in particular, may be a good idea.

Sorry, I didn't meant to sound so rough again ;). Let's say these are
just loose comments.

Tomek