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

[Evan Schoenberg]

In the length of my email, one point got lost, I believe, based on  
your reply, Graham:
> the advantages of switching to other libraries have grown smaller  
> in the meantime.  Mark Doliner has refactored and reorganized the  
> libgaim OSCAR prpl <snip>  It is now clean enough to support future  
> development.  Its AIM file transfer and direct connect are quite  
> reliable now.

which is to say that the file transfer / direct connect advantage of  
joscar over libgaim is no longer nearly as significant.

On Dec 7, 2006, at 9:01 PM, Graham Booker wrote:

>> 2) Client-side rate limiting management, which among other things  
>> allows rapid retrieval of away messages at sign-on
>
> I have considered actually implementing this in the past, but you  
> seem to indicate below that it is there now.  There is one strange  
> thought that nags at the back of my mind.  If this were implemented  
> along with non-blocking IO (which I have implemented as well), then  
> there is a buffer after the rate-limiting.  In certain network  
> conditions, that buffer can negate the rate-limiting.  I do have to  
> admit, this is a minor issue, especially since joscar has the same  
> kind of non-blocking IO inside it.
That's an interesting point.  As a side note, joscar does *not* have  
the same kind of non-blocking IO, as apparently non-blocking sockets  
are difficult to work with in Java.  Instead, a thread runs for each  
OSCAR connection, and a dedicated queue manager uses it to send in a  
non-blocking fashion.

>> 3) AIM file transfer resume and folder transfer
>
> Implemented within Fire's libfaim code.  I believe it is actually  
> complete as well.  I actually wrote this code about 4 years ago,  
> and so I am sure that it is completely incompatible with gaim's  
> current file transfer interface.  The hooks shouldn't be too hard  
> to change.
Indeed - it worked great in Fire when I was trying to port it to Gaim  
about 2 years ago.  I didn't succeed at the time, but with the gaim  
refactoring I suspect it will be much easier to address.

>> 4) Trillan SecureIM compatibility
>
> Can't answer to this one.  I only partially looked at it.  Since  
> Fire had GPG, and then later OTR, I just didn't see the point.  In  
> terms of implementation, I remember thinking it should be a plugin,  
> like OTR, but have extra "meta-data" support by the library to work  
> with it.  I would have to look at how secureIM is implemented again  
> in order to expound on this idea.
Indeed -- I don't expect that there's any real reason to implement  
SecureIM. Multiple encryption methods seems to add a lot of  
complexity which most users simply don't need.

> Wasn't there something about supporting AIM's encryption for IMs in  
> there as well?
I'm not sure... there may well have been.

>> 5) AIM GetFile support
>
> This is not hard to implement in the least.  First start a OFT  
> connection in almost identical means to above.  Then, send a simple  
> command which requests the file listing.  Then requesting a file is  
> another command.  After that, the actual file sending is identical  
> to file transfer listed above.
Oh, that's schnazzy.

> Just be aware, the file listing is a text file with constant column  
> widths.  I think it limited the filesize to something like 7 or 8  
> digits, in decimal, so no big files here.
And that's asinine :) Good word to the wise!

-Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20061207/0389c3af/attachment-0001.html>
-------------- 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/0389c3af/attachment.sig>