If the GPL doesn't work for your project, get in touch (cont...@meteor.com)
> and we will write you a commercial license to your specifications. We are > happy to be flexible. What's important is that we have a conversation about > how you are using Meteor, and what support and further development you > need, so we can keep everyone in the community on the same page.
I would have rather seen MIT, but I'm sure the authors have their reasons.
On Wed, Apr 11, 2012 at 12:16 AM, Nikolay Yasinskiy <h16...@gmail.com>wrote:
It's an interesting concept, and certainly impressive from a technological perspective in many respects. That being said, it seems so prone to exploit on a number of levels. They had to take down the demo that was running last night because someone had the bright idea of basically inserting items in an infinite loop via the console which seemed to cause stability issues on the server side.
I'm sure they have mechanisms in place to abate these concerns, but I wonder if you'll end up spending more time on those than you would save on the aspects that Meteor is designed to speed up (sync'ing, real time updates, etc.). Also, messing up real time sync'ing doing it by hand means there's most likely a harmless (from a data consistency standpoint) bug in your app. Messing up the protections around client side data access mean that someone gets access to data they shouldn't (or worse, can write data they shouldn't!).
On Wed, Apr 11, 2012 at 7:50 AM, Bradley Meck <bradley.m...@gmail.com> wrote: > Very interesting, but im worried about XSS attacks and form refreshes since > it is automatically sharing/refreshing parts of the page.
> On Wednesday, April 11, 2012 2:16:28 AM UTC-5, Nikolay Yasinskiy wrote:
I don't think that the security concerns are any more of an issue than they are with any other platform (including one you build yourself). If you have a JS api on the client side which is somewhat capable, it's going to be an issue.
On Wed, Apr 11, 2012 at 9:46 AM, Joshua Cohen <defea...@gmail.com> wrote: > It's an interesting concept, and certainly impressive from a > technological perspective in many respects. That being said, it seems > so prone to exploit on a number of levels. They had to take down the > demo that was running last night because someone had the bright idea > of basically inserting items in an infinite loop via the console which > seemed to cause stability issues on the server side.
> I'm sure they have mechanisms in place to abate these concerns, but I > wonder if you'll end up spending more time on those than you would > save on the aspects that Meteor is designed to speed up (sync'ing, > real time updates, etc.). Also, messing up real time sync'ing doing it > by hand means there's most likely a harmless (from a data consistency > standpoint) bug in your app. Messing up the protections around client > side data access mean that someone gets access to data they shouldn't > (or worse, can write data they shouldn't!).
> On Wed, Apr 11, 2012 at 7:50 AM, Bradley Meck <bradley.m...@gmail.com> > wrote: > > Very interesting, but im worried about XSS attacks and form refreshes > since > > it is automatically sharing/refreshing parts of the page.
> > On Wednesday, April 11, 2012 2:16:28 AM UTC-5, Nikolay Yasinskiy wrote:
On Wed, Apr 11, 2012 at 4:04 AM, Marak Squires <marak.squi...@gmail.com>wrote:
> Looks neat, but the license is GPL.
> In the faq, it says:
> If the GPL doesn't work for your project, get in touch (cont...@meteor.com) >> and we will write you a commercial license to your specifications. We are >> happy to be flexible. What's important is that we have a conversation about >> how you are using Meteor, and what support and further development you >> need, so we can keep everyone in the community on the same page.
> I would have rather seen MIT, but I'm sure the authors have their reasons.
I am almost always a supporter of MIT licenses, but they're right. It's not AGPL, which means you can build your commercial web-based applications on it. And even if you need to "distribute" some portion of it to the client, serving it from a CDN and your application code separately will cover this (Meteor becomes a library)
On Wed, Apr 11, 2012 at 7:31 AM, Chris Rhoden <carho...@gmail.com> wrote:
> On Wed, Apr 11, 2012 at 4:04 AM, Marak Squires <marak.squi...@gmail.com>wrote:
>> Looks neat, but the license is GPL.
>> In the faq, it says:
>> If the GPL doesn't work for your project, get in touch ( >>> cont...@meteor.com) and we will write you a commercial license to your >>> specifications. We are happy to be flexible. What's important is that we >>> have a conversation about how you are using Meteor, and what support and >>> further development you need, so we can keep everyone in the community on >>> the same page.
>> I would have rather seen MIT, but I'm sure the authors have their >> reasons.
> I am almost always a supporter of MIT licenses, but they're right. It's > not AGPL, which means you can build your commercial web-based applications > on it. And even if you need to "distribute" some portion of it to the > client, serving it from a CDN and your application code separately will > cover this (Meteor becomes a library)
>> On Wed, Apr 11, 2012 at 12:16 AM, Nikolay Yasinskiy <h16...@gmail.com>wrote:
+1 an interesting start but needs serious attention to security. Some are comparing it to Clipper, dBase, FoxPro (before MS bought it) - those were great products (I'm old enough to have used them) and built lots of productive apps, BUT, those were all pre-web, pre-wireless, pre-cloud where security is now a huge and unavoidable issue. The developers say they are addressing auth/auth in the future - it will be interesting to watch this project or future projects building upon the good parts of this.
> It's an interesting concept, and certainly impressive from a > technological perspective in many respects. That being said, it seems > so prone to exploit on a number of levels. They had to take down the > demo that was running last night because someone had the bright idea > of basically inserting items in an infinite loop via the console which > seemed to cause stability issues on the server side.
> I'm sure they have mechanisms in place to abate these concerns, but I > wonder if you'll end up spending more time on those than you would > save on the aspects that Meteor is designed to speed up (sync'ing, > real time updates, etc.). Also, messing up real time sync'ing doing it > by hand means there's most likely a harmless (from a data consistency > standpoint) bug in your app. Messing up the protections around client > side data access mean that someone gets access to data they shouldn't > (or worse, can write data they shouldn't!).
> On Wed, Apr 11, 2012 at 7:50 AM, Bradley Meck<bradley.m...@gmail.com> wrote: >> Very interesting, but im worried about XSS attacks and form refreshes since >> it is automatically sharing/refreshing parts of the page.
>> On Wednesday, April 11, 2012 2:16:28 AM UTC-5, Nikolay Yasinskiy wrote: >>> meteor.com/screencast >>> meteor.com/examples >> -- >> Job Board: http://jobs.nodejs.org/ >> Posting guidelines: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> You received this message because you are subscribed to the Google >> Groups "nodejs" group. >> To post to this group, send email to nodejs@googlegroups.com >> To unsubscribe from this group, send email to >> nodejs+unsubscribe@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en
Overall very interesting and looks promising. Like many on here already stated, how they address security will be interesting. Talking directly to the DB (as shown in the screencast) opens the door to a lot of concern. In a client->server->db model at least you have the server abstracting access to the db. yes it can also be hacked but at least you made it a little bit more difficult and can easily apply access rules rather than try to do it directly on the db side.
My main concern is that this makes it very easy for people with little understanding of the underlying systems to build somewhat comprehensive applications. It's too easy to make mistakes and assumptions that will bite them and their users later on. If someone sees that screencast, copy a simple example and build a small eCommerce site. They could potentially put their users and personal data in serious risk.
It's not to say that the Meteor guys can't fix this, it just means they need to pay very close attention to it early on rather than wait or it will be a big problem and jeopardize the project.
Besides these concerns, I love what they did. The hot code push is awesome and simple, the API is simple and easy to use. Really did a good job. Just please pay attention to security.
On Wed, Apr 11, 2012 at 19:24, rhasson <rhas...@gmail.com> wrote: > Overall very interesting and looks promising. Like many on here already > stated, how they address security will be interesting. Talking directly to > the DB (as shown in the screencast) opens the door to a lot of concern. In > a client->server->db model at least you have the server abstracting access > to the db. yes it can also be hacked but at least you made it a little bit > more difficult and can easily apply access rules rather than try to do it > directly on the db side.
> My main concern is that this makes it very easy for people with little > understanding of the underlying systems to build somewhat comprehensive > applications. It's too easy to make mistakes and assumptions that will > bite them and their users later on. If someone sees that screencast, copy > a simple example and build a small eCommerce site. They could potentially > put their users and personal data in serious risk.
> It's not to say that the Meteor guys can't fix this, it just means they > need to pay very close attention to it early on rather than wait or it will > be a big problem and jeopardize the project.
> Besides these concerns, I love what they did. The hot code push is > awesome and simple, the API is simple and easy to use. Really did a good > job. Just please pay attention to security.
> Roy
> On Wednesday, April 11, 2012 3:16:28 AM UTC-4, Nikolay Yasinskiy wrote:
I had to include the functionality of meteor in my app, including direct access to the db. In order to do this I am proxying the db access through node and checking permissions. If couchdb's permissions didn't suck so much I could have gone direct.
This isn't actually direct, that's not the way that, for instance, mongodb works. I wasn't going to say anything but it's clear that this is a misconception lots of people have.
The database is necessarily proxied through the server side application for all datastores aside from couchdb at this time. Authentication will be added to the server side component of meteor, and it will behave EXACTLY THE SAME as all other frameworks in this regard.
On Wed, Apr 11, 2012 at 1:55 PM, Mark Hahn <m...@hahnca.com> wrote: > I had to include the functionality of meteor in my app, including direct > access to the db. In order to do this I am proxying the db access through > node and checking permissions. If couchdb's permissions didn't suck so > much I could have gone direct.
Nobody noticed the node-fibers dep? It'll be interesting to see the
pressure build to get fibers/coroutines in core if this gains in
popularity (likely if you look at the HN score).
From the docs:
"Meteor gathers all your JavaScript files, excluding anything under
the client and public subdirectories, and loads them into a Node.js
server instance inside a fiber. In Meteor, your server code runs in a
single thread per request, not in the asynchronous callback style
typical of Node. We find the linear execution model a better fit for
the typical server code in a Meteor application."
On Apr 11, 5:16 pm, Nikolay Yasinskiy <h16...@gmail.com> wrote:
> It'll be interesting to see the pressure build to get fibers/coroutines > in core if this gains in > popularity (likely if you look at the HN score).
Knowing some of the core team I don't really think this will happen. In the unlikely event of a water landing, it wouldn't be because of pressure of some framework or HN. :)
On Thu, Apr 12, 2012 at 4:20 AM, Nuno Job <nunojobpi...@gmail.com> wrote: > It'll be interesting to see the pressure build to get fibers/coroutines >> in core if this gains in >> popularity (likely if you look at the HN score).
> Knowing some of the core team I don't really think this will happen. In > the unlikely event of a water landing, it wouldn't be because of pressure > of some framework or HN. :)
I think it's safe to say it won't ever, regardless of pressure. Especially since es6 has an equivalently expressive feature -- generators (shallow continuations) w/o the well-documented problem of fibers (deep continuations). (And no, this is not to flame fibers. I think they're really interesting and useful as a stop gap for people that like that style until they have generators.)
I do wonder though -- does anyone know if they're faking fibers on the client side? The demo shows sync interaction with the db -- are they using sync xhr? Or is it some crazy fancy rewriting, or some other exotic technique? They just did some hand-waving about latency compensation and I couldn't find anything in the docs.
On Thu, Apr 12, 2012 at 8:27 AM, Dean Landolt <d...@deanlandolt.com> wrote:
> On Thu, Apr 12, 2012 at 4:20 AM, Nuno Job <nunojobpi...@gmail.com> wrote:
>> It'll be interesting to see the pressure build to get >>> fibers/coroutines in core if this gains in >>> popularity (likely if you look at the HN score).
>> Knowing some of the core team I don't really think this will happen. In >> the unlikely event of a water landing, it wouldn't be because of pressure >> of some framework or HN. :)
> I think it's safe to say it won't ever, regardless of pressure. Especially > since es6 has an equivalently expressive feature -- generators (shallow > continuations) w/o the well-documented problem of fibers (deep > continuations). (And no, this is not to flame fibers. I think they're > really interesting and useful as a stop gap for people that like that style > until they have generators.)
> I do wonder though -- does anyone know if they're faking fibers on the > client side? The demo shows sync interaction with the db -- are they using > sync xhr? Or is it some crazy fancy rewriting, or some other exotic > technique? They just did some hand-waving about latency compensation and I > couldn't find anything in the docs.
It's very very unlikely that they'd be able to do that. It looks like they have a MongoDB query parser in the package, so the most likely thing seems to me to be that the query is executed against whatever data already exists on the client (in cache) and then the object returned is backfilled with additional data when it comes back from the server. Because of the "everything realtime" principle, it seems like it would be conceptually simple to just update the dataset when the query finished executing and treat it the same on the application side as new records.
I haven't gotten deep enough into the code to see how it works, but that's my gut.
Can anyone compare and contrast Meteor with Derby or Mojito? Or vanilla Node, for that matter? They all look nice, but I'm not sure what tradeoffs they make.
> Can anyone compare and contrast Meteor with Derby or Mojito? Or vanilla
> Node, for that matter? They all look nice, but I'm not sure what tradeoffs
> they make.
