Re: [Development] API review request: CBOR Stream reader and writer
On Wednesday, 17 January 2018 13:25:53 PST Thiago Macieira wrote: > Another idea is to update the network-chat example to use CBOR instead of > its plaintext protocol. In this one, I could use the stream reader and > writer. This example is a perfect candidate to have a CoAP version in the > future too. I've done this then: https://codereview.qt-project.org/217078 https://codereview.qt-project.org/217079 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] API review request: CBOR Stream reader and writer
Hello
I finished writing the documentation for the two basic classes for CBOR. You
can find them in reviews
https://codereview.qt-project.org/107465
https://codereview.qt-project.org/107466
Please review. I will take a couple more days writing the docs for
QCbor{Value,Map,Array} and then I'll upload that too.
I'm also interested in what I could write as an example. Please send
suggestions.
My current idea is a command-line tool that converts between serialisation
formats:
* CBOR
* CBOR diagnostic notation (output only, since I won't write the parser)
* JSON
* XML
* Qt binary JSON
* Plain QDataStream (output only, since it's not self-describing)
* QDataStream-serialised QVariant (is self-describing)
Though, because of the conversions, this example is ideal for QCborValue, not
the stream reader and writer.
Another idea is to update the network-chat example to use CBOR instead of its
plaintext protocol. In this one, I could use the stream reader and writer.
This example is a perfect candidate to have a CoAP version in the future too.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Undeprecating QString::null
On Tuesday, 16 January 2018 10:28:27 PST Uwe Rathmann wrote: > On Tue, 16 Jan 2018 18:38:48 +0100, Kevin Kofler wrote: > > So just use QString(), or define your own static instance of it if you > > really want to microoptimize it that much. > > No it is simply that the first version of Qwt was for Qt 1.2 ( before > QString even existed ) and during a history of almost 20 years there are > leftovers. Nitpick: QString existed in Qt 1.2, it just wasn't the QString we know. It was actually the predecessor to Qt 2's QCString, which in Qt 4 became Q3CString and was deprecated by QByteArray. > I had missed the point, when the static instance had been replaced - > that's why I was erroneously concerned about BC breaks. There's still static data, but unlike the Qt 1 solution, it's not an instance of QString but just of the shared null data. Since Qt 5, it's also shared with QVector and QByteArray. That's why the constructor is just as efficient. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCoap: QNAM-like API or not
On Monday, 15 January 2018 23:40:03 PST Maurice Kalinowski wrote: > Personally, I do not see those two items (missing DTLS, release TP) > conflicting. The only "problem" which might exist, if DTLS takes too long > to implement and CoAP would stay for a very long time in TP mode. I don't see a way out, though I'm hoping it won't be the case. "No security" is just not acceptable. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Repository request: Qt Notifier
Please note that I have an issue: https://bugreports.qt.io/browse/QTBUG-44804 about notifications. Though I titled it wrong with "sending" which should be "receiving". I did successfully integrate Firebase on Android and iOS. I'm not sure what help you need, but I can give parts of my existing code. I don't know what has been done already though so I don't know how helpful it will be. Sent: Wednesday, January 17, 2018 at 3:41 AM From: "Ari Salmi" To: "development@qt-project.org" Subject: Re: [Development] Repository request: Qt Notifier Hi there, Thanks for asking: >Ari: can you give (or point us to, if it's already written up) an >over-view of what's supported, on which platforms, and how far the API, >seen by Qt code using it, is independent of choice of back-end ? >How far is it dependent on the Kaltiot service ? What is that ? >The blog post looks promising, at least :-) The purpose of the Qt Cloud messaging is to provide possibility to wrap platform specific push notification backend or implement full cross platform with Qt’s own components (e.g. against customer’s own backend). API itself is independent of the backend - developer can choose which one to use for his/her product. Or can implement (and contribute) own backend as well. Wrappers at the moment in QtCloudMessaging are: - Firebase Cloud Messaging support for Android and iOS - And Kaltiot embedded devices notification services. Kaltiot SDK also works on desktops so Kaltiot is a embedded notification service provider which is capable of handling, managing production level amount of devices (I guess there are no limit when negotiated with Kaltiot). Currently Kaltiot wrapper includes push notification service parts against their SDK. Going forward, next steps on this are to fine tune the SDK API. And find more fluent way to configure wrapped SDKs to make first time usage easier (currently needs few env. variables to point e.g. to downloaded Firebase SDK etc.) as it will help to implement more platform specific SDKs as backend. All the help on these are appreciated ! Current usage: There are few customers using this wrapper already in their mobile app production against Firebase. Also Kaltiot customer base is now growing due this. So I guess time used for creating this has been worthwhile and gives more opportunities to Qt be on the chosen platform for device & app development :) Br, Ari Päällä 16 January 2018 klo 22.10.09, Samuel Gaist (samuel.ga...@edeltech.ch) kirjoitti: > On 16 Jan 2018, at 15:04, Shawn Rutledge wrote: > > >> On 16 Jan 2018, at 14:49, Kari Oikarinen wrote: >> >> >> On 15.01.2018 17:25, Ryan Chu wrote: >>> Hi all, >>> I'm working on a task supporting "Push Notification" for Qt applications. This feature will be implemented on Android and iOS devices as the first stage. A new module called "Qt Notify" will be created for all platforms. Therefore I request a repository. >> >> This sounds like it overlaps with qtcloudmessaging which also seems >> to be about push notifications? Or are they actually about something >> different and I'm mixing things? >> >> http://blog.qt.io/blog/2018/01/02/qt-cloud-messaging-api-available-embedded-systems/ > > Good catch. So is the API suitable for expanding to mainstream platforms? > > Also “Qt Notifications” sounds too generic to me, and maybe a bit misleading… we know we need to add support for system/desktop notifications (like the sidebar on macOS, and other UIs on Android and iOS and others) and some work was supposed to be in the pipeline for that at some point - not that it needs its own repo, but this concept might still be the first association for many people. Cloud-based notification is more specific. Hi, The work you are thinking about is likely this one: https://codereview.qt-project.org/#/c/166456/. I’d be happy to reactivate it. Cheers Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Repository request: Qt Notifier
Hi there, Thanks for asking: >Ari: can you give (or point us to, if it's already written up) an >over-view of what's supported, on which platforms, and how far the API, >seen by Qt code using it, is independent of choice of back-end ? >How far is it dependent on the Kaltiot service ? What is that ? >The blog post looks promising, at least :-) The purpose of the Qt Cloud messaging is to provide possibility to wrap platform specific push notification backend or implement full cross platform with Qt’s own components (e.g. against customer’s own backend). API itself is independent of the backend - developer can choose which one to use for his/her product. Or can implement (and contribute) own backend as well. Wrappers at the moment in QtCloudMessaging are: - Firebase Cloud Messaging support for Android and iOS - And Kaltiot embedded devices notification services. Kaltiot SDK also works on desktops so Kaltiot is a embedded notification service provider which is capable of handling, managing production level amount of devices (I guess there are no limit when negotiated with Kaltiot). Currently Kaltiot wrapper includes push notification service parts against their SDK. Going forward, next steps on this are to fine tune the SDK API. And find more fluent way to configure wrapped SDKs to make first time usage easier (currently needs few env. variables to point e.g. to downloaded Firebase SDK etc.) as it will help to implement more platform specific SDKs as backend. All the help on these are appreciated ! Current usage: There are few customers using this wrapper already in their mobile app production against Firebase. Also Kaltiot customer base is now growing due this. So I guess time used for creating this has been worthwhile and gives more opportunities to Qt be on the chosen platform for device & app development :) Br, Ari Päällä 16 January 2018 klo 22.10.09, Samuel Gaist (samuel.ga...@edeltech.ch) kirjoitti: > On 16 Jan 2018, at 15:04, Shawn Rutledge wrote: > > >> On 16 Jan 2018, at 14:49, Kari Oikarinen wrote: >> >> >> On 15.01.2018 17:25, Ryan Chu wrote: >>> Hi all, >>> I'm working on a task supporting "Push Notification" for Qt applications. >>> This feature will be implemented on Android and iOS devices as the first >>> stage. A new module called "Qt Notify" will be created for all platforms. >>> Therefore I request a repository. >> >> This sounds like it overlaps with qtcloudmessaging which also seems >> to be about push notifications? Or are they actually about something >> different and I'm mixing things? >> >> http://blog.qt.io/blog/2018/01/02/qt-cloud-messaging-api-available-embedded-systems/ >> > > Good catch. So is the API suitable for expanding to mainstream platforms? > > Also “Qt Notifications” sounds too generic to me, and maybe a bit misleading… > we know we need to add support for system/desktop notifications (like the > sidebar on macOS, and other UIs on Android and iOS and others) and some work > was supposed to be in the pipeline for that at some point - not that it needs > its own repo, but this concept might still be the first association for many > people. Cloud-based notification is more specific. Hi, The work you are thinking about is likely this one: https://codereview.qt-project.org/#/c/166456/. I’d be happy to reactivate it. Cheers Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
