GSOC Chat log storage: My thoughts
tomkiewi at gmail.com
Thu Apr 25 10:13:39 EDT 2013
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.
More information about the Devel