6 ms·

Meteor and Qt

162 points by achipa 12y ago

jakozaur 12y ago
There is a lot opinions on HNews that Meteor is too monolithic and it's bad: https://news.ycombinator.com/item?id=8772563 https://news.ycombinator.com/item?id=8772563 However, that kind of projects show the opposite. It is in fact very modular.
- evo_9 12y ago
  The fact that so many dismissed it without giving it a serious look made me interested in seeing what it was really about. Long/short - it's an amazingly focused, fun and easy stack to work with. I think the fact that it's easy, or at least seems easy and probably because it's another javascript framework makes it an easy target to dismiss on HN. If you are coming from a web background like myself (aspx, ruby, etc) then it's quite a revelation how fast, fun and easy it is to work with.
  - tracker1 12y ago
    I think that Meteor is pretty awesome, but it isn't good for a lot of use cases out of the box... If you need really granular and flexible security around your models, the out of the box security isn't (or wasn't last I checked) good enough. Common case.. GROUP_A users can read/write their own documents, but only read other user's documents in that group... GROUP_B can read/write their own documents as well as all documents owned by users in GROUP_A. This is a pretty typical scenario for management chain permissions, but when I've looked ad Meteor and similar solutions it wasn't an option (or incredibly difficult to implement).
    - primigenus 12y ago
      At a high level, what you're describing is pretty straightforward to implement. You just publish the data a user has access to read, and you use allow/deny rules to determine which they can write to. You should take a look at the Roles package: https://github.com/alanning/meteor-roles https://github.com/alanning/meteor-roles I recommend taking another look at Meteor's security because although it's different to other platforms, different doesn't mean inferior. It's actually very powerful and simple once you get the hang of it.
      - tracker1 12y ago
        Cool... as I admitted it's been a long while since I've looked at implementations... last I looked, if you opened your Meteor server to the (html/web) client, the client could do nasty things to your backend database, or you had to implement some complicated and/or not very flexible permissions... I'm glad to see that this has changed.
    - lourd 12y ago
      This is more of a data modeling and permissions question, more dependent on the database choice rather than the framework I'd say. Since Meteor only supports Mongo right now, I'll use Mongo terms (collections & documents) Meteor gives you an accounts collection so you don't have to declare it yourself. But we do need to declare the Groups Collection Groups = new Mongo.Collection('groups'); Let's assume we want Users and Groups to have a many to many relation, so each User doc has an attribute `groups`. `groups` is an array of which each element is the unique id of a Group document. Similarly, Group documents have an attribute `members`, an array of which each element is a User document unique id. There is a third Collection needed, documents. Documents = new Mongo.Collection('documents'); Each document in the Documents Collection has an `owner` field that is the unique id of a Group document. To handle the security for inserting or updating the Documents Collection, you need to set 2 allow rules on the Collection to check if the document.owner is in the user.groups array. Documents.allow({ insert: function(userId, doc) { // doc's owner must be one of logged in user's groups return Meteor.user().groups.indexOf(doc.owner) > -1; }, update: function(userId, doc, field, modifier) { return Meteor.user().groups.indexOf(doc.owner) > -1; } } As for reading the document, you do that when declaring your Publications. Easiest would be to publish all of them, but you could also pass in a groupId or array of groupIds if you wanted to have some restrictions. Meteor.publish("documents", function() { return Documents.find(); };
      - uptownJimmy 12y ago
        I am not a hater, quite the contrary. I've messed around with Meteor just a bit, and loved it. But I cannot get my head around one thing: why in the world would anyone actually choose to use MongoDB over Postgres or MySQL ?Is there actually a use case where a NoSQL db would be as good or preferable? Or is it really all just a matter of people being intimidated by SQL? Because everything informed and trustworthy that I read on the subject says that NoSQL is simply not robust enough for doing anything more complicated than storing a list of names and email addresses for a simple user forum. That ain't gonna cut it for most apps.
        achipa 12y ago
- lostinpoetics 12y ago
  Agreed. I think a lot of that is based on Meteor (understandably) pushing their entire stack. I've always been intrigued by their docs which state: By default all apps include the meteor-platform package. This automatically pulls in the packages that make up the core Meteor stack. If you want to build your own custom stack, just remove meteor-platform from your app and add back in whichever of the standard packages you want to keep.[0] Granted, I've always used the full stack but I'd be interested in seeing some examples of taking a more modular approach at a lower level than adding packages on top of the core stack. [0] http://docs.meteor.com/#/full/usingpackages http://docs.meteor.com/#/full/usingpackages
  - achipa 12y ago
    True - even for DDP there are already a number of client libraries not strictly related to Meteor front-ends, as seen from http://meteorpedia.com/read/DDP_Clients http://meteorpedia.com/read/DDP_Clients
    - sordina 12y ago
      I just wrote the Haskell DDP client last week :)
achipa 12y ago
Hi, I'm Attila, the developer of Qondrite - the interface between Meteor and Qt in the article. If you have any questions, feel free to ask, I'm always looking for new perspectives, comments and will be happy to answer!
- billforsternz 12y ago
  Really impressive work, thank you. I intend taking an in-depth look later, but just at the moment I hope you'll indulge a more-or-less off topic question; What tool did you use to create the youtube demo on your blog ?
  - achipa 12y ago
    I used a Chrome extension - Screencastify ( https://www.screencastify.com/ https://www.screencastify.com/ )
    - billforsternz 12y ago
      Much appreciated, thanks.
adrianlmm 12y ago
What's the difference between this and Xamarin?
- achipa 12y ago
  This is a more full-stack approach - Qt and Xamarin are geared more towards creating standalone apps. What you get here is the reactive back-end (plus web-site for free). This setup can be used for both data and UI - you could for example publish a new UI (not just content), and all native apps would automatically be updated on the fly. If you take a look at the video - if you do this with Xamarin (or Qt) you would need to manually connect to a database or poll a RESTful service to see current data.
  - segphault 12y ago
    It's worth noting that if you wanted to create this kind of real-time app with a Xamarin frontend, you could do it quite easily with ASP.NET on the backend and SignalR.
    - achipa 12y ago
      That's certainly possible for the data part - but a lot harder for UI/code. With the method I'm using, you can actually push code AND UI to the client on the fly. As far as I know, that's a lot more difficult with Xamarin. Also, the licensing is a lot more flexible than with Xamarin and Qt does provide support for more platforms.
      - adrianlmm 12y ago
        It looks attractive, but at these times, the client application can be easily be auto-updated, that's how all applications work, including those made by Google.
        achipa 12y ago
        Just wondering - what auto-update mechanisms are we talking about when it comes to native apps?
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
- deleted 12y ago
  [deleted]
achipa 12y ago
There were some concerns as to how native this is - I'm not rendering any HTML. The client side does use the JSON-style QML, but that's just the declarative UI language of Qt - your high-performance code can be C++, Java, or whatever is the native language of the platform. If you wish, though, you can write your whole app in JavaScript, too, but that's an option, not a requirement.
rattray 12y ago
Wow, QML looks... really nice. Has anyone used it to deploy cross-platform apps to iOS/Android? What was your experience? Biggest drawbacks?
- Elv13 12y ago
  As of 2012: * Lack of documentation about QML itself (first and third party) * Unhandled or unsupported corner case like trees that are a pain to implement using recursive rectangles * Very limited set of widgets (this has improved) * Ubuntu/Blackberry/Sailfish/PlasmaActive SDK are incompatible You can hack your way around and get back a good old imperative QPainter and be done with it, but it kind of void the whole point.
  - achipa 12y ago
    In all honesty, Qt has come a long way since 2012 - QML is reasonably well documented nowadays. Controls (the widget library), while not a silver bullet, are good enough (at least on Android, haven't used iOS all that much) so normally you don't need to go as low as your own QPainter or even Rect-s.
jonpress 12y ago
Meteor is monolithic in that it forces your app to be structured in a particular way - It dictates how you should handle your data and how your scripts get loaded/bundled into your app. That said, I think it's much more flexible (and scalable - In a business sense) than a closed solutions like Firebase. I think Meteor is suitable for most projects and monolithic isn't always a bad thing - There is some negative stigma around the term but it's not entirely fair. People don't go around calling Linux 'monolithic' even though it is!
- sordina 12y ago
  It's definitely monolithic, but depending on what you're doing it can be a real time saver to have a lot of decisions made for you up-front.
dcsan 12y ago
This is really interesting. I use meteor for the web, but am frustrated with mobile html5 client clunkiness. If i understand: - your UI is written in QML. - you are using Asteroid to turn DDP protocol messages into JS events? - are you then reactively changing the QML markup and asking QT to re-render your UI? I'm interested how this part works. How granular is the reactive rendering, ie the whole page every update, or just changed components (like reactjs DOM diffing)? Have you dealt with other client side things like routing and page changes, or is it currently content for QML widgets? How far does QML allow native widgets like tab controls? Does a QML app end up just as janky as html5? Did you look at just having a QT application that would talk DDP? I guess QML looks like json/markup so it's more appealing for porting an existing meteor app, and it's markup rather than code, but some mapping to QT would presumably give much more control? How do you deal with client side logic? If QML is just a layout descriptor markup, if you need actual logic client side, how do you bridge between that and the meteor backend? I see Asteroid allows you to send data back and call Meteor.methods. Oh I see QML actually anticipates modules in JS: http://doc.qt.io/qt-5/qtquick-tutorials-samegame-samegame3-example.html http://doc.qt.io/qt-5/qtquick-tutorials-samegame-samegame3-e... http://doc.qt.io/qt-5/qtqml-modules-topic.html http://doc.qt.io/qt-5/qtqml-modules-topic.html Does QML support a webview component? In which case you could also mix in some pages just as webviews if you didn't want to rewrite your whole app in QML? Then again only attractive if the QT webview component uses latest chrome renderer at an OS level, and no JS bridge was required back to your app... that would be like a turducken anti-pattern. Overall very interesting, thanks for sharing!
- achipa 12y ago
  Yes, I'm using Asteroid to talk DDP/JSON with the rest of the Qt app. In the example, I'm using models (think MVC) and updating that model, which then automagically updates the UI. I'm not (yet) pushing the QML via Meteor, but that is the next logical step. Should the UI change (say, radioboxes instead of checkboxes), the plan is to do a diff and change altered components (this should be doable as QML's format is still close enough to JSON). QML already has a decent set of controls (http://doc.qt.io/qt-5/qtquickcontrols-index.html http://doc.qt.io/qt-5/qtquickcontrols-index.html) but I'm working on wrapping native components so there is full coverage of ALL components (this was actually one of my previous posts http://achipa.blogspot.com/2014/11/qml-wrappers-for-native-android.html http://achipa.blogspot.com/2014/11/qml-wrappers-for-native-a...) Of course, you could write a C++ DDP lib (and on the long run, probably should, merely for the performance boost), but asteroid and JS just made a proof-of-concept that much easier to build. QML is not just a layout descriptor - you can embed javascript in it. Think about QML as HTML written in JSON, but without the HTML implied semantics. Still, JS could also be shuttled accross the DDP connection, and could be run or changed client-side, there is no difference between those and QML as I mentioned above, though this is also something planned-but-not-implemented-yet. And finally - yes, QML has a webview component(http://doc-snapshot.qt-project.org/qt5-5.4/qtwebengine-qmlmodule.html http://doc-snapshot.qt-project.org/qt5-5.4/qtwebengine-qmlmo...)
antoniuschan99 12y ago
My stack uses Appcelerator, Rails, and Meteor. Appcelerator... kind of sucks. But it's much better than HTML5. It performs much better than HTML5, but I find it very hard to write. There's just way too much quirkiness and hacks to make it work. The only thing I like about it is that it's written in JavaScript (but it would be fun to learn a new one). How does QT compare in this regard?
- achipa 12y ago
  Performance-wise Qt is quite good, but still comes up a bit short on the Widget quality and consistency side - this is where project like my native component-wrappers come in to the story (shameless plug - http://achipa.blogspot.com/2014/11/qml-wrappers-for-native-android.html http://achipa.blogspot.com/2014/11/qml-wrappers-for-native-a...). The good news is that you can still keep on the JSON/Javascript side for all of this, regardless of whether you use custom UIs, use Qt Quick Controls or something else. Long story short - it's not quite an Appcelerator replacement just yet, but certainly keep an eye on it! :)
Matthias247 12y ago
If you want a higher-level cross-platform websocket layer between client and server you could also checkout WAMP (http://wamp.ws http://wamp.ws) as an alternative to DDP. You would need to implement some things on your own, but on the other hand it's more of an open standard and there are already multiple targets available.
- achipa 12y ago
  Looks nice - Meteor natively speaks DDP so it makes most sense to use when talking to Meteor, but for other back-ends I will certainly consider WAMP! (no reason why this principle could not be applied to other back-ends hooking into the same WS powered Qt front-end)

162 points by achipa 12y ago

There is a lot opinions on HNews that Meteor is too monolithic and it's bad: https://news.ycombinator.com/item?id=8772563 https://news.ycombinator.com/item?id=8772563 However, that kind of projects show the opposite. It is in fact very modular.

evo_9 12y ago
The fact that so many dismissed it without giving it a serious look made me interested in seeing what it was really about. Long/short - it's an amazingly focused, fun and easy stack to work with. I think the fact that it's easy, or at least seems easy and probably because it's another javascript framework makes it an easy target to dismiss on HN. If you are coming from a web background like myself (aspx, ruby, etc) then it's quite a revelation how fast, fun and easy it is to work with.
- tracker1 12y ago
  I think that Meteor is pretty awesome, but it isn't good for a lot of use cases out of the box... If you need really granular and flexible security around your models, the out of the box security isn't (or wasn't last I checked) good enough. Common case.. GROUP_A users can read/write their own documents, but only read other user's documents in that group... GROUP_B can read/write their own documents as well as all documents owned by users in GROUP_A. This is a pretty typical scenario for management chain permissions, but when I've looked ad Meteor and similar solutions it wasn't an option (or incredibly difficult to implement).
  - primigenus 12y ago
    At a high level, what you're describing is pretty straightforward to implement. You just publish the data a user has access to read, and you use allow/deny rules to determine which they can write to. You should take a look at the Roles package: https://github.com/alanning/meteor-roles https://github.com/alanning/meteor-roles I recommend taking another look at Meteor's security because although it's different to other platforms, different doesn't mean inferior. It's actually very powerful and simple once you get the hang of it.
    - tracker1 12y ago
      Cool... as I admitted it's been a long while since I've looked at implementations... last I looked, if you opened your Meteor server to the (html/web) client, the client could do nasty things to your backend database, or you had to implement some complicated and/or not very flexible permissions... I'm glad to see that this has changed.
  - lourd 12y ago
    This is more of a data modeling and permissions question, more dependent on the database choice rather than the framework I'd say. Since Meteor only supports Mongo right now, I'll use Mongo terms (collections & documents) Meteor gives you an accounts collection so you don't have to declare it yourself. But we do need to declare the Groups Collection Groups = new Mongo.Collection('groups'); Let's assume we want Users and Groups to have a many to many relation, so each User doc has an attribute `groups`. `groups` is an array of which each element is the unique id of a Group document. Similarly, Group documents have an attribute `members`, an array of which each element is a User document unique id. There is a third Collection needed, documents. Documents = new Mongo.Collection('documents'); Each document in the Documents Collection has an `owner` field that is the unique id of a Group document. To handle the security for inserting or updating the Documents Collection, you need to set 2 allow rules on the Collection to check if the document.owner is in the user.groups array. Documents.allow({ insert: function(userId, doc) { // doc's owner must be one of logged in user's groups return Meteor.user().groups.indexOf(doc.owner) > -1; }, update: function(userId, doc, field, modifier) { return Meteor.user().groups.indexOf(doc.owner) > -1; } } As for reading the document, you do that when declaring your Publications. Easiest would be to publish all of them, but you could also pass in a groupId or array of groupIds if you wanted to have some restrictions. Meteor.publish("documents", function() { return Documents.find(); };
    - uptownJimmy 12y ago
      I am not a hater, quite the contrary. I've messed around with Meteor just a bit, and loved it. But I cannot get my head around one thing: why in the world would anyone actually choose to use MongoDB over Postgres or MySQL ?Is there actually a use case where a NoSQL db would be as good or preferable? Or is it really all just a matter of people being intimidated by SQL? Because everything informed and trustworthy that I read on the subject says that NoSQL is simply not robust enough for doing anything more complicated than storing a list of names and email addresses for a simple user forum. That ain't gonna cut it for most apps.
      - achipa 12y ago
lostinpoetics 12y ago
Agreed. I think a lot of that is based on Meteor (understandably) pushing their entire stack. I've always been intrigued by their docs which state: By default all apps include the meteor-platform package. This automatically pulls in the packages that make up the core Meteor stack. If you want to build your own custom stack, just remove meteor-platform from your app and add back in whichever of the standard packages you want to keep.[0] Granted, I've always used the full stack but I'd be interested in seeing some examples of taking a more modular approach at a lower level than adding packages on top of the core stack. [0] http://docs.meteor.com/#/full/usingpackages http://docs.meteor.com/#/full/usingpackages
- achipa 12y ago
  True - even for DDP there are already a number of client libraries not strictly related to Meteor front-ends, as seen from http://meteorpedia.com/read/DDP_Clients http://meteorpedia.com/read/DDP_Clients
  - sordina 12y ago
    I just wrote the Haskell DDP client last week :)

achipa 12y ago

Hi, I'm Attila, the developer of Qondrite - the interface between Meteor and Qt in the article. If you have any questions, feel free to ask, I'm always looking for new perspectives, comments and will be happy to answer!

billforsternz 12y ago
Really impressive work, thank you. I intend taking an in-depth look later, but just at the moment I hope you'll indulge a more-or-less off topic question; What tool did you use to create the youtube demo on your blog ?
- achipa 12y ago
  I used a Chrome extension - Screencastify ( https://www.screencastify.com/ https://www.screencastify.com/ )
  - billforsternz 12y ago
    Much appreciated, thanks.

adrianlmm 12y ago

What's the difference between this and Xamarin?

achipa 12y ago
This is a more full-stack approach - Qt and Xamarin are geared more towards creating standalone apps. What you get here is the reactive back-end (plus web-site for free). This setup can be used for both data and UI - you could for example publish a new UI (not just content), and all native apps would automatically be updated on the fly. If you take a look at the video - if you do this with Xamarin (or Qt) you would need to manually connect to a database or poll a RESTful service to see current data.
- segphault 12y ago
  It's worth noting that if you wanted to create this kind of real-time app with a Xamarin frontend, you could do it quite easily with ASP.NET on the backend and SignalR.
  - achipa 12y ago
    That's certainly possible for the data part - but a lot harder for UI/code. With the method I'm using, you can actually push code AND UI to the client on the fly. As far as I know, that's a lot more difficult with Xamarin. Also, the licensing is a lot more flexible than with Xamarin and Qt does provide support for more platforms.
    - adrianlmm 12y ago
      It looks attractive, but at these times, the client application can be easily be auto-updated, that's how all applications work, including those made by Google.
      - achipa 12y ago
        Just wondering - what auto-update mechanisms are we talking about when it comes to native apps?

deleted 12y ago

[deleted]

deleted 12y ago

[deleted]

deleted 12y ago
[deleted]

achipa 12y ago

There were some concerns as to how native this is - I'm not rendering any HTML. The client side does use the JSON-style QML, but that's just the declarative UI language of Qt - your high-performance code can be C++, Java, or whatever is the native language of the platform. If you wish, though, you can write your whole app in JavaScript, too, but that's an option, not a requirement.

rattray 12y ago

Wow, QML looks... really nice. Has anyone used it to deploy cross-platform apps to iOS/Android? What was your experience? Biggest drawbacks?

Elv13 12y ago
As of 2012: * Lack of documentation about QML itself (first and third party) * Unhandled or unsupported corner case like trees that are a pain to implement using recursive rectangles * Very limited set of widgets (this has improved) * Ubuntu/Blackberry/Sailfish/PlasmaActive SDK are incompatible You can hack your way around and get back a good old imperative QPainter and be done with it, but it kind of void the whole point.
- achipa 12y ago
  In all honesty, Qt has come a long way since 2012 - QML is reasonably well documented nowadays. Controls (the widget library), while not a silver bullet, are good enough (at least on Android, haven't used iOS all that much) so normally you don't need to go as low as your own QPainter or even Rect-s.

jonpress 12y ago

Meteor is monolithic in that it forces your app to be structured in a particular way - It dictates how you should handle your data and how your scripts get loaded/bundled into your app. That said, I think it's much more flexible (and scalable - In a business sense) than a closed solutions like Firebase. I think Meteor is suitable for most projects and monolithic isn't always a bad thing - There is some negative stigma around the term but it's not entirely fair. People don't go around calling Linux 'monolithic' even though it is!

sordina 12y ago
It's definitely monolithic, but depending on what you're doing it can be a real time saver to have a lot of decisions made for you up-front.

dcsan 12y ago

This is really interesting. I use meteor for the web, but am frustrated with mobile html5 client clunkiness. If i understand: - your UI is written in QML. - you are using Asteroid to turn DDP protocol messages into JS events? - are you then reactively changing the QML markup and asking QT to re-render your UI? I'm interested how this part works. How granular is the reactive rendering, ie the whole page every update, or just changed components (like reactjs DOM diffing)? Have you dealt with other client side things like routing and page changes, or is it currently content for QML widgets? How far does QML allow native widgets like tab controls? Does a QML app end up just as janky as html5? Did you look at just having a QT application that would talk DDP? I guess QML looks like json/markup so it's more appealing for porting an existing meteor app, and it's markup rather than code, but some mapping to QT would presumably give much more control? How do you deal with client side logic? If QML is just a layout descriptor markup, if you need actual logic client side, how do you bridge between that and the meteor backend? I see Asteroid allows you to send data back and call Meteor.methods. Oh I see QML actually anticipates modules in JS: http://doc.qt.io/qt-5/qtquick-tutorials-samegame-samegame3-example.html http://doc.qt.io/qt-5/qtquick-tutorials-samegame-samegame3-e... http://doc.qt.io/qt-5/qtqml-modules-topic.html http://doc.qt.io/qt-5/qtqml-modules-topic.html Does QML support a webview component? In which case you could also mix in some pages just as webviews if you didn't want to rewrite your whole app in QML? Then again only attractive if the QT webview component uses latest chrome renderer at an OS level, and no JS bridge was required back to your app... that would be like a turducken anti-pattern. Overall very interesting, thanks for sharing!

achipa 12y ago
Yes, I'm using Asteroid to talk DDP/JSON with the rest of the Qt app. In the example, I'm using models (think MVC) and updating that model, which then automagically updates the UI. I'm not (yet) pushing the QML via Meteor, but that is the next logical step. Should the UI change (say, radioboxes instead of checkboxes), the plan is to do a diff and change altered components (this should be doable as QML's format is still close enough to JSON). QML already has a decent set of controls (http://doc.qt.io/qt-5/qtquickcontrols-index.html http://doc.qt.io/qt-5/qtquickcontrols-index.html) but I'm working on wrapping native components so there is full coverage of ALL components (this was actually one of my previous posts http://achipa.blogspot.com/2014/11/qml-wrappers-for-native-android.html http://achipa.blogspot.com/2014/11/qml-wrappers-for-native-a...) Of course, you could write a C++ DDP lib (and on the long run, probably should, merely for the performance boost), but asteroid and JS just made a proof-of-concept that much easier to build. QML is not just a layout descriptor - you can embed javascript in it. Think about QML as HTML written in JSON, but without the HTML implied semantics. Still, JS could also be shuttled accross the DDP connection, and could be run or changed client-side, there is no difference between those and QML as I mentioned above, though this is also something planned-but-not-implemented-yet. And finally - yes, QML has a webview component(http://doc-snapshot.qt-project.org/qt5-5.4/qtwebengine-qmlmodule.html http://doc-snapshot.qt-project.org/qt5-5.4/qtwebengine-qmlmo...)

antoniuschan99 12y ago

My stack uses Appcelerator, Rails, and Meteor. Appcelerator... kind of sucks. But it's much better than HTML5. It performs much better than HTML5, but I find it very hard to write. There's just way too much quirkiness and hacks to make it work. The only thing I like about it is that it's written in JavaScript (but it would be fun to learn a new one). How does QT compare in this regard?

achipa 12y ago
Performance-wise Qt is quite good, but still comes up a bit short on the Widget quality and consistency side - this is where project like my native component-wrappers come in to the story (shameless plug - http://achipa.blogspot.com/2014/11/qml-wrappers-for-native-android.html http://achipa.blogspot.com/2014/11/qml-wrappers-for-native-a...). The good news is that you can still keep on the JSON/Javascript side for all of this, regardless of whether you use custom UIs, use Qt Quick Controls or something else. Long story short - it's not quite an Appcelerator replacement just yet, but certainly keep an eye on it! :)

Matthias247 12y ago

If you want a higher-level cross-platform websocket layer between client and server you could also checkout WAMP (http://wamp.ws http://wamp.ws) as an alternative to DDP. You would need to implement some things on your own, but on the other hand it's more of an open standard and there are already multiple targets available.

achipa 12y ago
Looks nice - Meteor natively speaks DDP so it makes most sense to use when talking to Meteor, but for other back-ends I will certainly consider WAMP! (no reason why this principle could not be applied to other back-ends hooking into the same WS powered Qt front-end)