Inclusion of MXit plugin into Pidgin

[Mark Doliner]

On Thu, Oct 29, 2009 at 9:17 AM, John Bailey <rekkanoryo at rekkanoryo.org> wrote:
> Pieter Loubser wrote:
>> There does not appear to be any other objections, so could you please
>> let me know what the next step will be to get this plugin included.
>
> The best thing to do would be to first have at least one person (but preferably
> two for backup purposes) from your group familiarize him/herself with monotone.

*snip*

> In either event, the people who will be given access to our mtn.pidgin.im
> netsync server will need to mail me the output of 'mtn pubkey <keyid>' where
> <keyid> is the key name they chose.  You will probably want to use your mxit.com
> email addresses as your key ID's for simplicity's sake.

Just want to update people on the status of MXit in libpurple.  The
protocol is checked into im.pidgin.pidgin (aka trunk) and I think both
Peter Loubser and Andrew Victor from MXit have commit access (I'm
assuming John did that--thanks John!).  The source will definitely be
included in our upcoming 2.6.4.

John you may have already talked to other devs about this, but I'm
totally ok with the MXit guys making changes directly to
im.pidgin.pidgin (you had suggested that they work in a branch, but I
couldn't tell if you thought they should ALWAYS work in a branch, or
only for the first release).  And Pieter, if you plan to make any
substantial changes to libpurple or Pidgin please work with another
developer to make sure we're familiar with the changes and everyone is
in agreement.

Also Pieter, I made a few small changes to your protocol code today in
im.pidgin.pidgin.  Just marked some strings for translation, got rid
of a few compile warnings (they maybe only happened on 64bit platforms
or with certain CFLAGS), maybe a small crash fix when getting an error
registering a new account, etc.  Please let me know if you have any
questions.

The only issue that I'm aware of is that struct raw_chunk in chunk.h
uses "__attribute__ ((packed))" which we believe is a gcc-only
compiler extension.  So this would break compilation with non-gcc
compilers.  I suspect that doesn't affect too many people, but it's
probably worth addressing before we release.  I don't know the best
way to address it.  Maybe separate the data field out of the struct
and set type and length separately based on the first few bytes from
the character array.

-Mark