[Adium-devl] Java-based libraries... a ponder, a thought, an apology

[Evan Schoenberg]

Guess this is my Colin impression for the week... here goes a long  
email:

About a year and a half ago, we began an experiment.  Could we  
manhandle the Cocoa-Java bridge -- largely undocumented -- into  
letting us utilize a promising Java library for AIM connectivity,  
joscar?  joscar offered many great features which libgaim's AIM  
implementation didn't.  Some choice selections:
1) Reliable AIM file transfer and direct connect
2) Client-side rate limiting management, which among other things  
allows rapid retrieval of away messages at sign-on
3) AIM file transfer resume and folder transfer
4) Trillan SecureIM compatibility
5) AIM GetFile support

We knew there were trade-offs from the get-go: without JNI or some  
sort of java-to-byte-code compiler, the Java Vritual Machine has to  
be running, which means increased memory usage, potentially increased  
CPU usage, and a startup delay.  The state of libgaim's AIM  
implementation was such that these seemed well worth it -- file  
transfer and direct connect through varying network conditions  
(anything but on the same LAN, basically) were effectively useless,  
and everything else joscar offered was very shiny.

Based on our decision to switch to joscar, we decided that there was  
no reason not to embrace other Java solutions, and Andreas, with  
Augie, and Alvaro worked on the Smack library throughout this past  
summer.  Alvaro's efforts can be seen in Smack itself -- only in the  
last weeks of the summer did he make changes within Adium, and those  
weren't specific to Smack.  Andreas, on the other hand, basically  
wrote a Jabber library based around Smack from the ground up.

I'm afraid we made a mistake and that it is better to correct it now  
than to wait longer.

The Cocoa-Java bridge is more than just 'largely undocumented', it  
turns out -- it's deprecated, which means it definitely won't work  
several years from now, and it's broken, which means it isn't  
particularly reliable right now.  It's broken in 10.5 developer  
builds, and there's no guarantee Apple will fix it even for 10.5, and  
it's broken in 10.4 and 10.3 in that it crashes oddly and randomly,  
with stack traces giving no indication of the source of the problem  
or with a simple console message related to memory management and an  
abort.

There are other options, theoretically, than the Cocoa-Java Bridge.   
Using JNI would be possible, most likely, but would be a huge time  
investment with questionable results in terms of performance.  The  
gjc compiler could potentially compile the libraries, but it's not  
Java-library feature complete yet and doesn't even compile on Darwin  
so far as I've been able to tell.

We don't have the resources to continue to fight the protocol fight,  
and we can't 'win' in any case when the enemy is an Apple decision  
not to continue support for the bridge.  In addition, speaking of  
resources, the RAM requirements of running the JavaVM knock us  
squarely out of the 'lightweight' category and into the 'heavyweight'  
-- something which I'd really like to avoid. We've wrestled all the  
various Java problems back and forth... but it's a losing battle.

It's a losing battle, and the advantages of switching to other  
libraries have grown smaller in the meantime.  Mark Doliner has  
refactored and reorganized the libgaim OSCAR prpl -- largely because  
of the impetus to change from us saying, "this is unusable, and we  
need to switch to something better."  It is now clean enough to  
support future development.  Its AIM file transfer and direct connect  
are quite reliable now.  In the past week and a half, he implemented  
rate limiting management, using an algorithm from the joscar docs.   
When it comes time for voice-video -- hopefully not too far in the  
future -- we will, I believe, find that with these cleanups and  
improvements it is very feasible to integrate the work Alan has  
already done on Fire's libfaim-based AIM implementation into libgaim.

I point that out that the joscar docs were integral to libgaim's  
implementation of the rate limiting logic because I don't want this  
to be a library fight -- I'm proud that our work with joscar has  
helped it improve and that other projects have picked it up for use.   
We're all on the same team.  There's still a ton to be learned from  
Keith Lea's fantastic work with joscar, and a future goal will  
definitely be to bring its other features into gaim's  
implementation.  The gaim folk are very willing to work toward the  
goal of a stable, feature-complete library intended for use in any UI  
which wants it.

***

I propose that we flip the #define back around to using libgaim for  
AIM and .Mac, then build and release Adium 1.0b16.  adium-joscar  
tickets which remain open in Trac will be marked invalid; closed  
adium-joscar tickets on the 1.0 milestone (which should just be ones  
which fixed Adium 0.8x bugs or added new features) should be  
reevaluated and either reopened or marked closed on the AIM  
component, as appropriate.  I've discussed this privately with David  
and Chris and, at the risk of putting words in their mouths, are in  
agreement -- at least with the general theme of this email if not its  
full contents :)

Not all work which has gone into joscar and Smack integration in  
Adium is a loss, by any means.  In the process of implementing each,  
many improvements were made to the Adium core.    Since the libgaim  
Jabber library now supports the addition of external plugins to add  
behaviors (for example, implementing the gmail mail checking  
extension no longer requires modifications to the libgaim jabber code  
itself), the higher-level work which was done for Smack can probably  
be ported to working as a libgaim plugin as appropriate.

Thoughts?

-Evan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20061207/67bd3f3e/attachment.sig>