|
|
Richard Danter wrote:
>2008/10/29 Thiago Macieira <thiago.macieira@xxxxxxxxxxxxx>:
>> First of all, I have to warn you that these two classes are not
>> considered a very good design. One of the reasons why that is so is
>> because they are fragile. It is somewhat related to the way they
>> operate, but mostly because they try to expose too much information
>> from the underlying protocol.
>
>If you were to re-write them, what would you do differently?
That's not a hypothetical question. I did rewrite them :-)
The result is QNetworkAccessManager, QNetworkRequest and QNetworkReply.
>Given the above comment about fragility, would you do this differently?
QNAM has a similar design as well. Some of the operations from the user
generate an internal event that gets processed in the event loop. In fact,
the guarantee that QNetworkReply is returned "opened but not finished" is
implemented by a "start event" that is posted before it is returned.
But one of the big differences is that we decided to expose much less of
the internal states. And we spread out via more abstract classes, allowing
us to better keep track of what is going on.
>Just a little more detail about the class. It contains a number of
>methods some of which are very quick to execute, like getting error
>codes and strings, and others may take some time to complete. Of the
>longer (time) methods, some could be broken up but others rely on
>functionality from other libs which are beyond my control.
Like I said above, the getters and setters are fast because they operate
on data that is already known. But the actual operating methods that
require communication with the backend will generate events.
--
Thiago Macieira - thiago.macieira (AT) nokia.com
Senior Software Engineer - Nokia, Qt Software
Qt Software is hiring - ask me
Sandakerveien 116, NO-0402 Oslo, Norway
|
|