[Adium-devl] Ticket #4501

[Graham Booker]

On Dec 7, 2007, at 9:04 AM, Augie Fackler wrote:

>
> On Dec 7, 2007, at 9:17 AM, Colin Barrett wrote:
>
>> On Dec 7, 2007, at 6:11 AM, Peter Hosey wrote:
>>
>>> On Dec 07, 2007, at 06:02:53, Colin Barrett wrote:
>>>> How about instead a bundle, we just use an extended attribute?
>>>
>>> What would this be useful for, besides continuing the progress
>>> display in the FT window across multiple runs of Adium?
>>
>>
>> It wouldn't affect the UI -- it would just signal that the file is
>> incomplete and if it is not being written to, should be swept up
>> later.
>>
>> Really, I'm wondering why we don't just Trash the file when the
>> transfer fails.
>
> We explicity *don't* trash the file for the purpose of resumes. That's
> why I want a bundle - so the user doesn't have half-completed
> transfers sitting around waiting to be opened (and possibly corrupted
> via "repair") but still resumable.
>

A bundle also allows us to store some extra side information to allow  
for resumes.  The most obvious thing to store from my viewpoint is any  
state that must be computed when a resume is attempted.  In the case  
of AIM, this would be the checksum (it is computed in the initial  
transfer anyway, so might as well just save it).  This would save  
recomputing this number to try a resume.  Second may be the service  
and username of the sender, to indicate to the user from whom they  
should request the file again.

This has uses even if we don't support resume for this service.  We  
could make it so if the user launched the bundle, Adium would take it,  
and display a dialog or window with the information about the file,  
including the sender and service.  That would solve the "Hmm..   
someone sent me this file, but it has a funny icon, ok, I'll open it  
to see what the deal is.  Oh, Adium says the transfer didn't complete,  
ok, I'll ask my friend for it again."  I think that's better than it  
failing, ending up in the trash, and the user wonders where the file  
went (I know too many people who just click ok to dialog boxes without  
reading them).

Also, AIM supports a file sharing of sort, sort of like an fserve,  
though it isn't used much.  In such a case, it is possible for the  
receiver to resume the transfer on their own (if adium supported it :P).

> Augie
>
>>
>>
>> -Colin
>>
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3632 bytes
Desc: not available
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20071207/005927c6/attachment.p7s>