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
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 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 have the same
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 is
Le Nov 9, 2011 à 10:14 AM, André Somers a écrit :
On Wed, Nov 9, 2011 at 9:17 AM, Jeremy Lainé jeremy.la...@m4x.org 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
On 11/09/2011 07:41 PM, Giuseppe D'Angelo wrote:
On 9 November 2011 18:35, Jeremy Lainéjeremy.la...@m4x.org 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
Le Jan 4, 2012 à 11:47 AM, Peter Hartmann a écrit :
On 01/03/2012 01:07 PM, ext Thiago Macieira wrote:
On Tuesday, 3 de January de 2012 09.53.41, Jonas M. Gastal wrote:
As for removing them entirely yes, it would require changes in the HTTP
socket engine and QAuthenticator. But given that
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 a
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 simply
- 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
I have found QML's network transparency very handy for loading whole UIs over
the network, it makes it possible for instance to have live updates to an
application provided all the changes happen on the QML side. However, once
internationalization comes into play, there's a catch: unless I'm
Le Jul 31, 2012 à 9:34 AM, Alan Alpert a écrit :
On Mon, 30 Jul 2012 19:34:23 ext Jeremy Lainé wrote:
I have found QML's network transparency very handy for loading whole UIs
over the network, it makes it possible for instance to have live updates
to an application provided all the changes
On 07/31/2012 01:16 PM, lars.kn...@nokia.com wrote:
You should uninstall the old one. For several translators it's better if we
use either several TranslationLoader elements or have a special property
taking an array of source files.
I have done what you suggest, and uninstall the old
On 11/04/2013 05:13 PM, Robert Knight wrote:
Thanks for your work on QtNetwork Shane!
Same here, thanks a lot Shane for your work and for your patience getting
QDnsLookup into
shape!
Jeremy
___
Development mailing list
Development@qt-project.org
On 04/28/2014 11:44 AM, Nichols Andy wrote:
It is possible still in the packaged versions of Qt for iOS to make
connections using SSL via QNetworkAccessManager as there is a backend that
uses Apples crypto API, but without OpenSSL support you can’t use any of the
API’s in Qt that use
On 29 Apr 2014 00:39, Thiago Macieira thiago.macie...@intel.com wrote:
Em ter 29 abr 2014, às 00:16:43, Jeremy Lainé escreveu:
What would the best course of action be to add support for secure
websockets
on iOS?
Probably to add a new QSslSocket backend that uses the Apple API.
OK
On 04/29/2014 02:39 PM, Sorvig Morten wrote:
This aproach looks promising. If we can get basic QSslSocket working (enough
for say QNAM and QWebSocket) then retiring the NSUrlConnection backend and
focusing on QSslSocket is a possibility.
OK I have moved my proof of concept code here:
On 04/30/2014 11:42 AM, Peter Hartmann wrote:
Yeah, nice work! I think it would be a good thing to get this into qtbase
(should you be
willing to contribute this of course); providing only a subset of the QSsl*
functionality sounds perfectly fine to me...
I have created a qssl-ios branch in
On 05/01/2014 03:51 PM, Jeremy Lainé wrote:
One problem I am going to run into is that Apple's API doesn't seem to
provide error
details when a certificate check fails (SecTrustEvaluate), so I don't think
we'll get as
fine-grained QSslError's as when using OpenSSL. I have however managed
Thanks Richard for taking the time to write up your summary, as the subject is
pretty vast.
On 05/03/2014 11:23 PM, Richard Moore wrote:
Support for QNAM
It's obvious that to be useful, a backend must allow QNAM to make SSL
requests. It need not support the more advanced
A while back I posted some proof of concept code to show what an
implementation of QSslSocket might look like using Secure Transport. I
have continued along these lines, and wanted to keep you updated.
1. GENERAL
Apple's Secure Transport API is available both on OS X and iOS. As I do
not have
, Jeremy Lainé jeremy.la...@m4x.org
mailto:jeremy.la...@m4x.org wrote:
A while back I posted some proof of concept code to show what an
implementation of QSslSocket might look like using Secure
Transport. I
have continued along these lines, and wanted to keep you updated.
1
On 09/06/2014 01:19 PM, Валерий Котов wrote:
There is one more thing. Should we care about cross-origin resource
sharing protocol? If I got it right, XMLHttpeRequset should perform
OPTIONS preflight request before real cors request. Please see links
below for more details:
Hi,
I am currently trying to finalize an SSL backend using SecureTransport to add
SSL support
for iOS and/or replace the OpenSSL backend for OSX [1].
When this backend is configured the following should get defined:
QT_NO_OPENSSL
QT_SECURETRANSPORT
To achieve this I modifed the configure
On 02/22/2015 06:57 PM, Richard Moore wrote:
Slightly off-topic but related : does the Qt Company have any
privileged access to Apple engineers working on Secure Transport?
I would like to understand what the plans are regarding support
for NPN / ALPN.
No idea on that
Hi Rich,
On 02/21/2015 06:30 PM, Richard Moore wrote:
Here's an outline of stuff I'd like to see get done in the Qt 5.6 time
frame:
* Complete removal of openssl 0.9.8 support
This has been unsupported for a while and was really only retained
since it is the only version apple ship on OS X
On 02/22/2015 06:42 PM, Richard Moore wrote:
On 22 February 2015 at 17:39, Jeremy Lainé jeremy.la...@m4x.org
mailto:jeremy.la...@m4x.org wrote:
Whilst I agree with the goal of dropping support for old /
unmaintained
OpenSSL versions, in the case of OS X we probably need to map
On 04/13/2015 03:46 PM, Nurmi J-P wrote:
On 13 Apr 2015, at 14:50, Jeremy Lainé jeremy.la...@m4x.org wrote:
How about just android-controls, which would become
qt-android-controls if the project graduates from playground?
I like this suggestion. In the end we will have much more (*) than just
On 04/13/2015 01:21 PM, Nurmi J-P wrote:
Thanks for the ideas, keep it coming! :) We should probably follow the
guidelines: https://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt
How about just android-controls, which would become
qt-android-controls if the project graduates from playground?
On 05/29/2015 04:27 PM, Denis Shienkov wrote:
So, any payload of data is in 8 bytes.. and all of input/output is
carried out by messages, but not separate bytes (as in
sockets/pipes/serialport).
I don't know as how will look the CanDevice (derived from QIODevice),
because
30 matches
Mail list logo
