GSoC 2013

Tomasz Wasilczyk tomkiewicz at cpw.pidgin.im
Wed Mar 20 09:59:11 EDT 2013


2013/3/20 Michael Zangl <pidgin_m at fam-zangl.de>:
> Having the "heavy" chat connections that desktop PCs use is not the
> most power efficient way to send simple text messages, but if I cared that
> much about power I would use SMS. I don't have any actual figures on how
> much power running pidgin takes.

If I would like to use SMS instead of IM services, I'd buy Nokia
6310i. This implementation doesn't let android go into idle mode, so
even without any benchmarks we could say, It will drain battery.
That's serious issue for me, when I want it running all the time in
background (to always stay online).

> The main advantage of libpurple is that it
> supports many protocols out of the box without me needing to trust some
> online service or installing something on a different PC.

I think, a compromise can be worked out: Android client could support
both methods - using your ported libpurple to work out-of-the-box, or
connect to remote host to become synchronized with PC and
power-saving. It would be ultimate solution for me.

> Your idea to proxy messages from the desktop to the mobile is good, but I
> don't think it should be an android privilege. We could add this to
> libpurple and make it a basic feature

Android one could be the first client that uses the same protocol
(based on cloud messaging service and Protocol Buffers, let's say). On
(host) libpurple side it would be implemented by a core plugin.

> so that you can connect different
> libpurple clients that automatically synchronize accounts and chatlogs and
> also manage connections when there are multiple instances online at the same
> time (that means, the desktop connects to ICQ and the mobile just gets the
> messages from it).

I was thinking exactly that way.

Anyway, this is only one project proposal - we're dealing with
Pidgin's participation in GSoC at all right now. I think further
discussion about Android port/client should be continued in a separate
thread.

Tomek




More information about the Devel mailing list