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

[Graham Booker]

On Dec 7, 2006, at 8:31 PM, Evan Schoenberg wrote:

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

Ah yes, I did miss that.  I figured it was just a matter of time  
since I last looked at the code.

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

(writing this more for future reference, so a quick description of  
this stuff is at hand)
When I said the same kind, I was referring to the generic "write this  
to a buffer and that buffer will write to a socket".  Wether that  
buffer is in the OS, in the virtual machine, or a dedicated queue.   
What you described for joscar is almost identical to what I did for  
libfaim:
Add the data to send to a buffer
Attempt to flush the buffer using non-blocking IO
If the buffer is non-empty, ask the client to call a handler when  
data can be written.
Keep writing out that buffer until it is empty, then suspect the  
handler calls.

Same concept, but when the IO read wouldn't block, skips the queue.   
Non-blocking reads is where things get a lot more interesting.   
Writes is not a terrible issue, but when you use satellite internet,  
non-blocking reads is a must!
Attempt to read the header, if not enough data, abort and wait for more
Read the header and attempt to read the rest of the packet.  If not  
enough data, again abort and wait for more.

With the routines I wrote, this should be a simple patch into  
libfaim, and I have yet to find a case where it breaks anything.
Most of the details are here:
http://trac.fireim.org/dev/browser/trunk/fire/AIM-oscar/oscar/ 
conn.c#L955
and looking at all instances of aim_bstream_recv in http:// 
trac.fireim.org/dev/browser/trunk/fire/AIM-oscar/oscar/rxqueue.c  
(returning -2 means that the data is not all here yet).

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

This just needs a few extra hooks from the file transfer interface  
back to the library.  The only catch is the checksum can sometimes  
come into play here, so it had better be computed.  I *think* I still  
remember how to do it.  If not, I should be able to find it digging  
through Fire's code.

> <snip>
> -Evan



- Graham


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20061207/141f62e3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1603 bytes
Desc: not available
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20061207/141f62e3/attachment.p7s>