On 01/06/2012 06:46 PM, ext Jeremy Lainé wrote:
>> - finalise the class name (I think QDns was suggested)
>>
>
> Could we get this point settled once and for all? My suggestions:
>
> - QDnsLookup (my preferred one, as the object represents a lookup and its
> result)
I like the name too...
> - QD
On 07/01/2012, at 4:46 AM, Jeremy Lainé wrote:
>> - finalise the class name (I think QDns was suggested)
>>
>
> Could we get this point settled once and for all? My suggestions:
>
> - QDnsLookup (my preferred one, as the object represents a lookup and its
> result)
+1 Says exactly what the
On Friday, 6 de January de 2012 18.46.16, Jeremy =?ISO-8859-1?Q?Lainé?wrote:
> > - finalise the class name (I think QDns was suggested)
>
> Could we get this point settled once and for all? My suggestions:
>
> - QDnsLookup (my preferred one, as the object represents a lookup and its
> result)
Go f
> - finalise the class name (I think QDns was suggested)
>
Could we get this point settled once and for all? My suggestions:
- QDnsLookup (my preferred one, as the object represents a lookup and its
result)
- QDnsInfo (similar to QHostInfo)
- QDns
Jeremy
___
Hi,
On 05/01/2012, at 1:11 AM, ext Thiago Macieira wrote:
> On Thursday, 5 de January de 2012 12.07.37, craig.sc...@csiro.au wrote:
>> On 05/01/2012, at 11:47 AM, Thiago Macieira wrote:
>>> On Thursday, 5 de January de 2012 11.03.42, craig.sc...@csiro.au wrote:
This could be perceived as cre
On 01/05/2012 01:03 AM, craig.sc...@csiro.au wrote:
>> Some notes about the implementation:
>>
>> - the actual lookup code is run in a thread, managed by a global threadpool
>> (QHostInfo-style)
> What happens if the client/user is also employing their own thread pool? Does
> your implementation
On 01/05/2012 01:47 AM, Thiago Macieira wrote:
> On Thursday, 5 de January de 2012 11.03.42, craig.sc...@csiro.au wrote:
>> This could be perceived as creating a race condition. You'd have to connect
>> a slot to the signal on the object returned, but what if the signal is
>> emitted before you get
On Thursday, 5 de January de 2012 12.51.50, craig.sc...@csiro.au wrote:
> Ah, the reply object emits the signal in the same thread as the caller? I
> was assuming the signal is emitted from within the thread that is
> processing the reply. Yes, in that case connecting before returning to the
> even
On 05/01/2012, at 12:11 PM, Thiago Macieira wrote:
> On Thursday, 5 de January de 2012 12.07.37, craig.sc...@csiro.au wrote:
>> On 05/01/2012, at 11:47 AM, Thiago Macieira wrote:
>>> On Thursday, 5 de January de 2012 11.03.42, craig.sc...@csiro.au wrote:
This could be perceived as creating a
On Thursday, 5 de January de 2012 12.07.37, craig.sc...@csiro.au wrote:
> On 05/01/2012, at 11:47 AM, Thiago Macieira wrote:
> > On Thursday, 5 de January de 2012 11.03.42, craig.sc...@csiro.au wrote:
> >> This could be perceived as creating a race condition. You'd have to
> >> connect
> >> a slot
On 05/01/2012, at 11:47 AM, Thiago Macieira wrote:
> On Thursday, 5 de January de 2012 11.03.42, craig.sc...@csiro.au wrote:
>> This could be perceived as creating a race condition. You'd have to connect
>> a slot to the signal on the object returned, but what if the signal is
>> emitted before y
On Thursday, 5 de January de 2012 11.03.42, craig.sc...@csiro.au wrote:
> This could be perceived as creating a race condition. You'd have to connect
> a slot to the signal on the object returned, but what if the signal is
> emitted before you get a chance to do that?
It cannot happen if you make
On 05/01/2012, at 3:51 AM, Jeremy Lainé wrote:
> Replying to myself to try and get the discussion going again.
>
> A summary of API decisions so far:
>
> - we only provide an asynchronous API
>
> - we do not want a "manager" object (QNAM-style) to avoid users creating a
> manager per lookup
>
Replying to myself to try and get the discussion going again.
A summary of API decisions so far:
- we only provide an asynchronous API
- we do not want a "manager" object (QNAM-style) to avoid users creating a
manager per lookup
- we want a single class to support different types of DNS reques
On Thursday, 10 de November de 2011 07.54.55, Jeremy Lainé wrote:
> What I mean is that the Q3Dns has setters as well as a constructor with
> arguments, so for instance:
>
> Q3Dns *dns = new Q3Dns;
> dns->setLabel("foodomain.org");// will a request be triggered if I stop here
> and don't specify th
On Wednesday, 9 de November de 2011 19.21.14, Peter Hartmann wrote:
> We probably can mitigate the complexity introduced by QSharedPointer by
> having a simple example in the documentation.
Note: add QSharedPointer and QWeakPointer overloads to QObject::connect.
--
Thiago Macieira - thiago (AT)
On 11/09/2011 07:41 PM, Giuseppe D'Angelo wrote:
> On 9 November 2011 18:35, Jeremy Lainé wrote:
>> C/ you make QDnsReply's constructor public, and let the user manage the
>> lifetime of the
>> object. This is what the Q3Dns API looks like. What I don't like about
>> Q3Dns's API is that
>> it's
Op 9-11-2011 19:35, Jeremy Lainé schreef:
> On 11/09/2011 07:21 PM, Peter Hartmann wrote:
>> On 11/09/2011 06:43 PM, ext Jeremy Lainé wrote:
>>> (...)
>>> A/ static QDnsReply* QDnsReply::lookup(QDnsReply::Type, QString);
>>>
>>> pro: easy to connect to the QDnsReply's signal
>>> con: it's entirely
On 9 November 2011 18:35, Jeremy Lainé wrote:
> C/ you make QDnsReply's constructor public, and let the user manage the
> lifetime of the
> object. This is what the Q3Dns API looks like. What I don't like about
> Q3Dns's API is that
> it's unclear when the request is actually made.
It starts af
On 11/09/2011 07:21 PM, Peter Hartmann wrote:
> On 11/09/2011 06:43 PM, ext Jeremy Lainé wrote:
>> (...)
>> A/ static QDnsReply* QDnsReply::lookup(QDnsReply::Type, QString);
>>
>> pro: easy to connect to the QDnsReply's signal
>> con: it's entirely up to the user to handle deletion. Judging by your
On 11/09/2011 06:43 PM, ext Jeremy Lainé wrote:
> (...)
> A/ static QDnsReply* QDnsReply::lookup(QDnsReply::Type, QString);
>
> pro: easy to connect to the QDnsReply's signal
> con: it's entirely up to the user to handle deletion. Judging by your
> comments above, I
> doubt you favor it?
>
> or
>
On Wednesday 09 November 2011 18:05:52 Jeremy Lainé wrote:
> This talk about QtConcurrent has me wondering: do we need an asynchronous
> API at all?
>
> The underlying system calls are blocking anyway, and we could maybe have a
> very simple API like:
>
> QDnsInfo QDnsInfo::lookup(QDnsInfo::Recor
On 11/09/2011 06:21 PM, Robin Burchell wrote:
> On Wed, Nov 9, 2011 at 6:05 PM, Jeremy Lainé wrote:
>> This talk about QtConcurrent has me wondering: do we need an asynchronous
>> API at all?
> I really dislike synchronous APIs, even more so when they're the only
> option. Reason being that most
On Wed, Nov 9, 2011 at 6:05 PM, Jeremy Lainé wrote:
> This talk about QtConcurrent has me wondering: do we need an asynchronous API
> at all?
I really dislike synchronous APIs, even more so when they're the only
option. Reason being that most 'normal' people won't make the effort
to get it right
This talk about QtConcurrent has me wondering: do we need an asynchronous API
at all?
The underlying system calls are blocking anyway, and we could maybe have a very
simple API like:
QDnsInfo QDnsInfo::lookup(QDnsInfo::RecordType type, const QString &domain)
And if you want asynchronous calls
On Nov 4, 2011, at 9:37 PM, ext Thiago Macieira wrote:
> On Friday, 4 de November de 2011 21:01:30 Andre Somers wrote:
>> Me too. My point was, that we have slightly different patters for
>> basically the same sort of thing in different places in Qt. QFuture is
>> currently coupled with QtConcu
On Wed, Nov 9, 2011 at 11:26 AM, Jeremy Lainé wrote:
>
> Le Nov 9, 2011 à 10:14 AM, André Somers a écrit :
>
>
>
> On Wed, Nov 9, 2011 at 9:17 AM, Jeremy Lainé wrote:
>
>> On 11/08/2011 10:57 PM, Thiago Macieira wrote:
>> > On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
>> >> - t
Le Nov 9, 2011 à 10:14 AM, André Somers a écrit :
>
>
> On Wed, Nov 9, 2011 at 9:17 AM, Jeremy Lainé wrote:
> On 11/08/2011 10:57 PM, Thiago Macieira wrote:
> > On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
> >> - the QNAM-style API seems to be OK
> > Correct, but all function
On Wed, Nov 9, 2011 at 9:17 AM, Jeremy Lainé wrote:
> On 11/08/2011 10:57 PM, Thiago Macieira wrote:
> > On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
> >> - the QNAM-style API seems to be OK
> > Correct, but all functions in QDnsResolver are static.
> >
> > That means they could
On Wednesday, 9 de November de 2011 09:17:59 Jeremy Lainé wrote:
> On 11/08/2011 10:57 PM, Thiago Macieira wrote:
> > On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
> >> - the QNAM-style API seems to be OK
> >
> > Correct, but all functions in QDnsResolver are static.
> >
> > That m
On 11/08/2011 10:57 PM, Thiago Macieira wrote:
> On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
>> - the QNAM-style API seems to be OK
> Correct, but all functions in QDnsResolver are static.
>
> That means they could go into QDnsReply and we could rename the class simply
> QDns. It
On Tuesday, 8 de November de 2011 19:40:13 Jeremy Lainé wrote:
> - the QNAM-style API seems to be OK
Correct, but all functions in QDnsResolver are static.
That means they could go into QDnsReply and we could rename the class simply
QDns. It worked for Qt 3...
> - I have implemented QDnsReply::a
On 11/04/2011 09:37 PM, Thiago Macieira wrote:
> On Friday, 4 de November de 2011 21:01:30 Andre Somers wrote:
>> Me too. My point was, that we have slightly different patters for
>> basically the same sort of thing in different places in Qt. QFuture is
>> currently coupled with QtConcurrent, but i
On Friday, 4 de November de 2011 21:01:30 Andre Somers wrote:
> Me too. My point was, that we have slightly different patters for
> basically the same sort of thing in different places in Qt. QFuture is
> currently coupled with QtConcurrent, but is there a strong reason why
> is must be? I was not
On 11/04/2011 09:01 PM, Andre Somers wrote:
> Op 4-11-2011 20:31, Jeremy Lainé schreef:
>> On 11/04/2011 10:15 AM, André Somers wrote:
>>> The more I think about it, the more I think it is important to fix this:
>>> who is
>>> responsible for the lifetime of the QDnsReply object?
>>>
>> Why not ha
Op 4-11-2011 20:31, Jeremy Lainé schreef:
> On 11/04/2011 10:15 AM, André Somers wrote:
>> The more I think about it, the more I think it is important to fix this: who
>> is
>> responsible for the lifetime of the QDnsReply object?
>>
> Why not have the same pattern as QNAM for consistency?
How abo
On 11/04/2011 11:47 AM, Peter Hartmann wrote:
> Btw. I think we need the generic accessor anyway because you never know
> what the format of a TXT response looks like. Q3Dns allowed that only
> for TXT records, but IMO it would be better to always have an accessor
> to the raw response data, or at
On 11/04/2011 10:15 AM, André Somers wrote:
>
> The more I think about it, the more I think it is important to fix this: who
> is
> responsible for the lifetime of the QDnsReply object?
>
Why not have the same pattern as QNAM for consistency?
> This API does not make that clear. I like the patt
Le Nov 4, 2011 à 11:05 AM, Thiago Macieira a écrit :
> On Friday, 4 de November de 2011 10:36:29 Peter Hartmann wrote:
>> I am happy with having one QDnsReply class; I think we can get pretty
>> far with some special accessors for SRV and other records, and one
>> generic accessor for simple (Q
On 11/04/2011 10:15 AM, ext André Somers wrote:
> (...)
> The more I think about it, the more I think it is important to fix this:
> who is responsible for the lifetime of the QDnsReply object?
>
> This API does not make that clear. I like the pattern in itself (also in
> QNAM), but I do think it w
On Friday, 4 de November de 2011 11:47:23 Peter Hartmann wrote:
> True, QByteArray then, but why would it be useless? You would just need
> to parse the response itself if the format is not supported, which would
> be easy for TXT, SOA, A6 etc. For CERT and other DNSSEC types you would
> have to do
On 11/04/2011 11:05 AM, ext Thiago Macieira wrote:
> On Friday, 4 de November de 2011 10:36:29 Peter Hartmann wrote:
>> I am happy with having one QDnsReply class; I think we can get pretty
>> far with some special accessors for SRV and other records, and one
>> generic accessor for simple (QString
On Friday, 4 de November de 2011 10:15:54 André Somers wrote:
> The more I think about it, the more I think it is important to fix this:
> who is responsible for the lifetime of the QDnsReply object?
>
> This API does not make that clear. I like the pattern in itself (also in
> QNAM), but I do thin
On Friday, 4 de November de 2011 10:36:29 Peter Hartmann wrote:
> I am happy with having one QDnsReply class; I think we can get pretty
> far with some special accessors for SRV and other records, and one
> generic accessor for simple (QString) and unsupported cases. Then
> whoever wants to read a
On 11/03/2011 08:32 PM, ext Jeremy Lainé wrote:
>
> Le Nov 3, 2011 à 7:10 PM, Peter Hartmann a écrit :
>
>> On 11/03/2011 04:12 PM, ext Thiago Macieira wrote:
>>> (...)
>>> The DNS query is not the problem. A query is always composed of a domain
>>> name
>>> being queried, along with the DNS class
2011/11/4 André Somers :
> Currently, the user
> will have to instantiate the QDnsResolver object, and call the lookupService
> method. It is not so clear what needs to happen to that instance after that.
which brings up a pet QNAM-peeve of mine - a frequent new-to-Qt user
trap is that they instan
On Thu, Nov 3, 2011 at 12:40 PM, Jeremy Lainé wrote:
> Based on some initial feedback I received regarding DNS SRV support in Qt,
> I have refactored my proposed code and introduced a "QDnsResolver" class
> which I would like to submit for API review. The point of this class is to
> provide a QNA
Le Nov 3, 2011 à 7:10 PM, Peter Hartmann a écrit :
> On 11/03/2011 04:12 PM, ext Thiago Macieira wrote:
>> (...)
>> The DNS query is not the problem. A query is always composed of a domain name
>> being queried, along with the DNS class (Internet, no one uses anything else
>> for real purposes) a
On 11/03/2011 04:12 PM, ext Thiago Macieira wrote:
> (...)
> The DNS query is not the problem. A query is always composed of a domain name
> being queried, along with the DNS class (Internet, no one uses anything else
> for real purposes) and the record type. For the record type, it's very easy to
On Thursday, 3 de November de 2011 15:45:31 Peter Hartmann wrote:
> > An open question: should we have multiple lookupXXX() methods, or a single
> > lookup() which takes a QDnsRequest?
> It might make sense to have a generic method for querying any type of
> DNS; but then would we need a QDnsReques
On 11/03/2011 12:40 PM, ext Jeremy Lainé wrote:
> Based on some initial feedback I received regarding DNS SRV support in Qt, I
> have refactored my proposed code and introduced a "QDnsResolver" class which
> I would like to submit for API review. The point of this class is to provide
> a QNAM-st
nt-bounces+shane.kearns=accenture@qt-project.org]
> On Behalf Of Jeremy Lainé
> Sent: Thursday, November 03, 2011 11:40
> To: development@qt-project.org
> Subject: [Development] API review for a new QDnsResolver class
>
> Based on some initial feedback I received regarding DNS
Based on some initial feedback I received regarding DNS SRV support in Qt, I
have refactored my proposed code and introduced a "QDnsResolver" class which I
would like to submit for API review. The point of this class is to provide a
QNAM-style asynchronous API to perform DNS lookups.
The resolv
53 matches
Mail list logo
