Looking for engin.io replacement -joining our effort initiative
-
Hi,
Don't start by dropping the PIMPL idiom from that module, especially if the goal is to get it integrated with the Qt distribution some day.
For more details about private implementation you can look here
-
@SGaist Thanks for this information, I wasn't aware of this...
Nevertheless, for now I would prefer YAGNI over PIMPL ;-)The private classes are mainly for binary compatibility that Qt has to maintain for all the Qt5 line, it's much simpler without that burden.
Actually, as far as I know, binary compatibility is guaranteed only between major versions, but not for the whole Qt 5 line. Meaning 5.X.Y are binary compatible across all .Y versions, but not between the .X versions. Or in other words, Qt 5.5.1 would be compatible with 5.5.2, 5.5.3 and so on, but 5.4 is not guaranteed to be binary compatible with 5.5.
Nevertheless, for now I would prefer YAGNI of PIMPL ;-)
I believe @SGaist's point is that you're in fact going to need it if you ever hope to have your module as part of Qt. :)
Otherwise you'd be asking everyone that uses your library to do a full rebuild of their code on any change in the private implementation of your module (like adding a member of a class for internal purposes) ... and this ain't a good way to design a library ...Kind regards.
-
The private classes are mainly for binary compatibility that Qt has to maintain for all the Qt5 line, it's much simpler without that burden.
Actually, as far as I know, binary compatibility is guaranteed only between major versions, but not for the whole Qt 5 line. Meaning 5.X.Y are binary compatible across all .Y versions, but not between the .X versions. Or in other words, Qt 5.5.1 would be compatible with 5.5.2, 5.5.3 and so on, but 5.4 is not guaranteed to be binary compatible with 5.5.
Nevertheless, for now I would prefer YAGNI of PIMPL ;-)
I believe @SGaist's point is that you're in fact going to need it if you ever hope to have your module as part of Qt. :)
Otherwise you'd be asking everyone that uses your library to do a full rebuild of their code on any change in the private implementation of your module (like adding a member of a class for internal purposes) ... and this ain't a good way to design a library ...Kind regards.
wrote on 24 Feb 2016, 10:14 last edited by gadlim@kshegunov said:
Actually, as far as I know, binary compatibility is guaranteed only between major versions, but not for the whole Qt 5 line. Meaning 5.X.Y are binary compatible across all .Y versions, but not between the .X versions. Or in other words, Qt 5.5.1 would be compatible with 5.5.2, 5.5.3 and so on, but 5.4 is not guaranteed to be binary compatible with 5.5.
No, there's binary compatibility for .X (minor) versions too
About the build dependencies, you're right, PIMPL is also better for that.
But I'll side this @Charby on this, it's a bit YAGNI at that point. The important thing is to get that project off the ground, and the code he's submitted is rather clean and simple, so easier to contribute to and build upon that the official Qt Enginio SDK. If someone wants to contribute a PIMPLification, I think he won't object (?), but I wouldn't be fair to require him to do that himself, as it would eat some of his time that can be better spent adding features. -
@kshegunov said:
Actually, as far as I know, binary compatibility is guaranteed only between major versions, but not for the whole Qt 5 line. Meaning 5.X.Y are binary compatible across all .Y versions, but not between the .X versions. Or in other words, Qt 5.5.1 would be compatible with 5.5.2, 5.5.3 and so on, but 5.4 is not guaranteed to be binary compatible with 5.5.
No, there's binary compatibility for .X (minor) versions too
About the build dependencies, you're right, PIMPL is also better for that.
But I'll side this @Charby on this, it's a bit YAGNI at that point. The important thing is to get that project off the ground, and the code he's submitted is rather clean and simple, so easier to contribute to and build upon that the official Qt Enginio SDK. If someone wants to contribute a PIMPLification, I think he won't object (?), but I wouldn't be fair to require him to do that himself, as it would eat some of his time that can be better spent adding features.No, there's binary compatibility for .X (minor) versions too
Right, either I have remembered wrongly, or the versioning system has changed somewhat from Qt 4. But in any case, using PIMPL is a good way to ensure all the aforementioned features.
But I'll side this @Charby on this, it's a bit YAGNI at that point.
I don't presume to tell you how to design or code your library, just throwing my 2 cents. ;)
but I wouldn't be fair to require him to do that himself, as it would eat some of his time that can be better spent adding features.
The only problem I see is that at a later point implementing PIMPL from existing code might be more involved, so I'd go with it from the start, but as I noted, it's up to the actual designer/programmer how to proceed. As a side note, the idiom doesn't actually require more work, only some care to separate the data from the interface. (If you wish you could take a peek at a library (wrap) I'm developing for OpenMPI, to have a baseline for what implementing PIMPL might involve).
Kind regards.
-
No, there's binary compatibility for .X (minor) versions too
Right, either I have remembered wrongly, or the versioning system has changed somewhat from Qt 4. But in any case, using PIMPL is a good way to ensure all the aforementioned features.
But I'll side this @Charby on this, it's a bit YAGNI at that point.
I don't presume to tell you how to design or code your library, just throwing my 2 cents. ;)
but I wouldn't be fair to require him to do that himself, as it would eat some of his time that can be better spent adding features.
The only problem I see is that at a later point implementing PIMPL from existing code might be more involved, so I'd go with it from the start, but as I noted, it's up to the actual designer/programmer how to proceed. As a side note, the idiom doesn't actually require more work, only some care to separate the data from the interface. (If you wish you could take a peek at a library (wrap) I'm developing for OpenMPI, to have a baseline for what implementing PIMPL might involve).
Kind regards.
wrote on 24 Feb 2016, 11:50 last edited by Charby@kshegunov Just to clarify slightly my words : when I mentioned my preference to YAGNI over PIMPL, I was not meaning that PIMPL implementation would not be needed : I have a better understanding of PIMPL now - thanks to you guys! - and I am convinced that I would definitely go for it.
Actually, I meant that my plugin design is not mature enough at this stage, I have only implemented one backend service (Parse) and it is not even complete...so it is likely that when adding new features (or even worst, when I will integrate new backend services) , I would need to change the design, modifying declaration, visibility and so on...and at this stage, it would be much faster if I only modify one class i.o two.
As far as I understood the PIMPL implementation, adding the private class when my plugin design would be mature enough should be a straightforward process. But if you think, I am missing something please tell me, so I could integrate PIMPL right away.Thanks for your feedback !
-
@kshegunov said:
Actually, as far as I know, binary compatibility is guaranteed only between major versions, but not for the whole Qt 5 line. Meaning 5.X.Y are binary compatible across all .Y versions, but not between the .X versions. Or in other words, Qt 5.5.1 would be compatible with 5.5.2, 5.5.3 and so on, but 5.4 is not guaranteed to be binary compatible with 5.5.
No, there's binary compatibility for .X (minor) versions too
About the build dependencies, you're right, PIMPL is also better for that.
But I'll side this @Charby on this, it's a bit YAGNI at that point. The important thing is to get that project off the ground, and the code he's submitted is rather clean and simple, so easier to contribute to and build upon that the official Qt Enginio SDK. If someone wants to contribute a PIMPLification, I think he won't object (?), but I wouldn't be fair to require him to do that himself, as it would eat some of his time that can be better spent adding features. -
wrote on 24 Feb 2016, 11:58 last edited by
Another but related topic : I have seen on the wiki, that it is encouraged to request for Qt playground project creation even if the project is in early stage. I think, that's would be great in this case so we could have a common repository to collaborate on a great plugin to give Qt App backend services.
Do you know how to proceed for creating playground projects ?
So far, I only sent a request on the development mailing list but I don't know what are the next steps... -
Another but related topic : I have seen on the wiki, that it is encouraged to request for Qt playground project creation even if the project is in early stage. I think, that's would be great in this case so we could have a common repository to collaborate on a great plugin to give Qt App backend services.
Do you know how to proceed for creating playground projects ?
So far, I only sent a request on the development mailing list but I don't know what are the next steps...@Charby
Hello,As far as I understood the PIMPL implementation, adding the private class when my plugin design would be mature enough should be a straightforward process. But if you think, I am missing something please tell me, so I could integrate PIMPL right away.
Mostly it's very straightforward process, however there are few "tricks" that are usually closely associated with the PIMPL idiom. I've used two of them in my project (sourced in my previous post), i.e. private slots and private object constructor. The private slots can be substituted with lamda functions if you're willing to enforce C++11. The second one can be implemented at a later stage, but I personally would detest refactoring a full working piece of code only to ensure that the user won't be able to create an object of given class. These two help with the design - not exposing anything besides the barebone interface, but you could certainly skip them (in most cases), or at least defer the[ir] implementation. I hope this is helpful.
Kind regards.
-
Another but related topic : I have seen on the wiki, that it is encouraged to request for Qt playground project creation even if the project is in early stage. I think, that's would be great in this case so we could have a common repository to collaborate on a great plugin to give Qt App backend services.
Do you know how to proceed for creating playground projects ?
So far, I only sent a request on the development mailing list but I don't know what are the next steps...wrote on 26 Feb 2016, 11:43 last edited by@Charby said:
Do you know how to proceed for creating playground projects ?
So far, I only sent a request on the development mailing list but I don't know what are the next steps...The wiki page says "wait for the approval of a maintainer on the mailing list", so the next step is to wait for a response, but as it's been a long time, a bump could help, maybe.
On an unrelated note, my pull request was merged into Parse Server today, so +1 to the Parse Server project. There's now a 100% features parity between the Engin.io REST API and the Parse Server API (at least for the subset I'm using, but Id say I'm using all the most common methods).
-
wrote on 3 Mar 2016, 23:22 last edited by
Just a short post to give feedbacks...
Unfortunately I haven't had too much time to continue working on the BaaS plugin lately, here is the project status :- Authentification : partly done (miss the social linking)
- Object (alias collection) management : done
- JSonModel : partly done (read-only only for now)
- Adaptative QML List view : done
- Files : work in progress, I should have it completed by tomorrow hopefully
As always, comments are welcome !
-
wrote on 5 Mar 2016, 01:34 last edited by
Files support is done - Next step is to support social login.
-
wrote on 31 Oct 2016, 20:02 last edited by
Hi @Charby,
I've just seen this post now. How did your integration go so far?There is a Qt optimized cloud/BaaS alternative: you can look at V-Play Game Network: http://v-play.net/game-network/
Albeit its name, it is not only for games but also for apps.See here for a list of useful components with their Qt API reference:
- http://v-play.net/doc/vplay-webstorage/ - use WebStorage as a cloud-based key/value store. Its data gets synced across devices & platforms.
- http://v-play.net/doc/vplay-vplaygamenetwork/ - GameNetwork supports social login from Facebook so data can be synced across devices & platforms with a single user.
- http://v-play.net/doc/vplay-vplaymultiplayer/ - The multiplayer components supports a chat, push notifications and a friend system. You can add a QML-stylable messenger to your app with this component.
You can also just use some parts of these components, and freely mix it for example with Firebase.
Cheers, Chris
-
Hi @Charby,
I've just seen this post now. How did your integration go so far?There is a Qt optimized cloud/BaaS alternative: you can look at V-Play Game Network: http://v-play.net/game-network/
Albeit its name, it is not only for games but also for apps.See here for a list of useful components with their Qt API reference:
- http://v-play.net/doc/vplay-webstorage/ - use WebStorage as a cloud-based key/value store. Its data gets synced across devices & platforms.
- http://v-play.net/doc/vplay-vplaygamenetwork/ - GameNetwork supports social login from Facebook so data can be synced across devices & platforms with a single user.
- http://v-play.net/doc/vplay-vplaymultiplayer/ - The multiplayer components supports a chat, push notifications and a friend system. You can add a QML-stylable messenger to your app with this component.
You can also just use some parts of these components, and freely mix it for example with Firebase.
Cheers, Chris
wrote on 2 Nov 2016, 14:21 last edited byHi @feldifux,
Actually I stopped working on this project for some time now. Currently the API is working fine with Parse server as datastorage. Support for social login and push notifications are missing.
V-Play Albeit sounds very nice !
I will definitely have a try the next time I would need social login or notifications support. Thanks -
Hi @feldifux,
Actually I stopped working on this project for some time now. Currently the API is working fine with Parse server as datastorage. Support for social login and push notifications are missing.
V-Play Albeit sounds very nice !
I will definitely have a try the next time I would need social login or notifications support. Thankswrote on 3 Nov 2016, 14:47 last edited bySounds good @Charby , if you need any help, just contact us via our support forums. You can also ping me directly here on the Qt forum. :)