GSOC Chat log storage: My thoughts

[Ethan Blanton]

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.

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

> 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:

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.

> 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.

Note that dropping the existing mysql requirement may be an
appropriate response.

Ethan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20130425/1f74db8f/attachment.sig>