[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    Re: [kopete-devel] [PATCH] Incoming file transfer in chat window
From:       "Roman Jarosz" <roman.jarosz () gmail ! com>
Date:       2008-08-17 16:44:17
Message-ID: op.uf1h33darj95b0 () localhost
[Download RAW message or body]

On Sun, 17 Aug 2008 17:12:41 +0200, Matt Rogers <mattr@kde.org> wrote:

> On Aug 16, 2008, at 8:23 PM, Olivier Goffart wrote:
>
>> Le vendredi 15 août 2008, Roman Jarosz a écrit :
>>> Hi
>>>
>>> I've removed the ugly dialog which is shown when we got file transfer
>>> request and moved it into the chat window.
>>>
>>> It's based on Adium chat style (FileTransferRequest.html) although
>>> to make
>>> it more user friendly I had to add four new keywords %fileSize%,
>>> %saveFileHandlerId%, %saveFileAsHandlerId%, %cancelRequestHandlerId%.
>>> The three id keywords are used to disable buttons after file transfer
>>> is accepted or rejected.
>>>
>>> If current style doesn't have FileTransferRequest.html Kopete creates
>>> default one based on current chat style.
>>>
>>> Here are screenshots:
>>> http://kedge.wz.cz/kopete/kopeteft1.png
>>> http://kedge.wz.cz/kopete/kopeteft2.png
>>> http://kedge.wz.cz/kopete/kopeteft3.png
>>
>> Cool, great works
>>
>> Comments:
>>
>> - PLEASE DO NOT ENABLE JAVASCRIPT BY DEFAULT!  No security whole in
>> kopete
>> please :-)      enable it on demand just when we need it.  but
>> javascript
>> injection stuff should not be possible.
>>
>
> Why not? Enabling javascript on its own does not expose us to security
> holes, and provides a boat laod of features. You even mention about
> that Javascript injection should not be possible. Now, it could be
> part of a malicious style that the user downloads, but there's not a
> lot we can do about that.

I don't see the problem too and if in the styly has some malicious code
it's better to be found right away then after you get file message request.

>> - there is a new fileTransferId  in Kopete::Message.  Could it
>> become a
>> message id.  It could be used for some others stuff (i'm thinking
>> about
>> aknoweldgement of messages)

This is good idea. Do we want the ID to be unique by Message type
or globally unique?

>> - internaly maybe the whole filtertansfer suff should go in a
>> different
>> structure in the d ptr,  because there are lot of messages, and few
>> of them
>> are file transfer messages

I agree that we should spilt it. Actually I was thinking about it
but didn't do it after all. I thought that we could make one base class
and then the normal, action and filetransfer message classes.

Or did you mean something else?

Roman

>
>
> Matt
>
> _______________________________________________
> kopete-devel mailing list
> kopete-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kopete-devel
>


_______________________________________________
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

[prev in list] [next in list] [prev in thread] [next in thread]