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

List:       kde-devel
Subject:    Re: QNetworkAccessManager and KDE's KIO
From:       Dario Freddi <drf54321 () gmail ! com>
Date:       2012-03-28 9:26:40
Message-ID: CAFFVnfOncKE78KVfoyjMxs0yXo7wAAfYn+nN_uTqsKH=jmf=ZQ () mail ! gmail ! com
[Download RAW message or body]

Il 28 marzo 2012 10:22, Weng Xuetian <wengxt@gmail.com> ha scritto:
> On Wed, Mar 28, 2012 at 3:46 PM, Dario Freddi <drf54321@gmail.com> wrote:
>> Il 23 marzo 2012 06:15, Weng Xuetian <wengxt@gmail.com> ha scritto:
>>> On Fri, Mar 23, 2012 at 6:53 AM, Albert Astals Cid <aacid@kde.org> wrot=
e:
>>>> El Dimarts, 20 de mar=E7 de 2012, a les 12:26:05, Weng Xuetian va escr=
iure:
>>>>> Hi,
>>>>
>>>> Hi
>>>>
>>>>> I'm currently implementing a library that require network access, and=
 I need
>>>>> some custom url such as "myapp://" to do oauth callback, so I create a
>>>>> class inherits QNetworkAccessManager.
>>>>>
>>>>> But I found if anyone want to KDE's KIO::Integration::AccessManager to
>>>>> replace the NetworkAccessManager in order to use KDE proxy setting an=
d KIO,
>>>>> there will be some problem. I don't want this library hardly depends =
on
>>>>> KDE, but I also hope it can integrate with KDE well.
>>>>>
>>>>> I read attica's code but seems it use a custom interface, which is not
>>>>> fesible here since I need to set the NetworkAccessManager to the QWeb=
View.
>>>>>
>>>>> Any idea about how to solve this problem? Is simply keep a pointer to=
 the
>>>>> old networkmanager and redirect createRequest to it enough?
>>>>
>>>> I think you could make your QNetworkAccessManager have a
>>>> setNonMyAppAccessManager() and then all the calls that happen to your
>>>> MyAppNetworkAccessManager that are not myapp:// you redirected them to=
 the
>>>> QNetworkAccessManager passed there.
>>>>
>>>> I'm not a huge expert in QNetworkAccessManager but it could work. So g=
ive it a
>>>> try :-)
>>>>
>>>> Cheers,
>>>> =A0Albert
>>>>
>>>>>
>>> I don't think so... since all other call to QNetworkAccessManager will =
be wrong.
>>
>> The solution Albert proposed is actually correct instead, and already
>> used by several other applications/libraries. Obviously, you would
>> have to construct a default QNetworkAccessManager if none is supplied
>> from the outside. This also would make your whole library
>> implementation more flexible also outside the KDE realm.
>>
>>>
>>> Anyway.. I try a different solution, create two plugin, which have the
>>> similar logic at the createRequest, though some of code are duplicate,
>>> but it's small and will works.
>>>
>>>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubsc=
ribe <<
>>
>>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscr=
ibe <<
>
> The problem is, I need to override the default createRequest, even for
> the KIO::AccessManager, in order to process OAuth custom callback.
>
> Here is my approach: https://github.com/csslayer/qcloud/tree/master/netwo=
rk/kde
>
> This is actually a plugin and can create custom networkaccessmanager
> object , which derive from KIO::AccessManager.

Now it's clear, thanks. Then indeed what you did seems to me the most
reasonable approach, but I see another potential problem. AFAIK
(probably other people more knowledgeable than me about the subject
could expand) one of the main points of KIO::AM is to actually
reimplement this function by providing a different reply, but you are
overriding it by feeding it a QCloud reply. I have the feeling your
QCloud reply might need some additional modifications to follow, for
example, proxy settings enforced by KIO::AM. But again, please double
check this information as this:

1. depends on what you are doing inside your reply, since I didn't
have time to look through all of the code
2. Is still something I'd like to have confirmed by somebody who knows
more than me about the topic.

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=
e <<
[prev in list] [next in list] [prev in thread] [next in thread]