[Telepathy] tp-qt4 FileTransfer API proposal

Andre Moreira Magalhaes andre.magalhaes at collabora.co.uk
Tue Sep 1 11:21:24 PDT 2009


Will Thompson wrote:
> George Goldberg wrote:
>   
>> However, I think the number of parameters there is
>> really frightening.
>>     
>
> Yes it is.
>
>   
>> If I understand the instructions below, you have to
>> call FileTransferChannel::provideFile() below anyway, so why does the
>> createFileTransfer method need all that information?
>>     
>
> Because when you Create a FT channel, the file is immediately offered to
> your peer. You have to call provideFile() before any data is sent, but
> the offer is sent immediately. So, any information you want to be in the
> offer (like the hash, so they can figure out if it's a file they've
> received part of before) has to be in the channel request.
>
> The ridiculous number of arguments is kind of unfortunate. One way
> around this could be (pardon my poor C++, I forget how to specify
> defaults):
>
>   class FTProps {
>     public:
>       FTProps(fileName, contentType, size);
>
>       FileHashType contentHashType = (FileHashType) -1;
>       const QString &contentHash = QString();
>       const QString &description = QString();
>       QDateTime lastModificationTime = QDateTime();
>       QDateTime userActionTime = QDateTime::currentDateTime();
>   }
>
>    PendingChannelRequest *createFileTransfer(
>      const QString &contactIdentifier,
>      const FTProps &props,
>      const QString &preferredHandler = QString());
>
> Maybe this is not idiomatic C++? But something like this would make it
> easier to see which props are optional, and make the method easier to
> read.
>
>
>   
I am really not sure what is better here, but as you agree that this 
seems better I can change.

In C++, the Props class would be something like:

class FTProps ...
{
       FTProps(fileName, contentType, size,
         FileHashType contentHashType = (FileHashType) -1, const QString 
&contentHash = QString(),  const QString &description = QString(),  
QDateTime lastModificationTime = QDateTime(),  QDateTime userActionTime 
= QDateTime::currentDateTime());

      QString fileName() const;
      QString contentType() const;
      ....
};

So changing it won't make much difference from what we have now. We 
would have a class with the constructor containing all the default 
values. Why let in the constructor? As they can't be changed after creation.

Ps.: Making the members public accessible is not an option, neither 
having setters methods for them, as they can't change after creation.

If we use this class, should we also use it on FTChannel instead of 
having the accessors for every property, should we have one accessor to 
return the props class?

BR
Andrunko


More information about the telepathy mailing list