[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