Meteor,what you think

[Nikolay Yasinskiy]

meteor.com/screencast
meteor.com/examples

[Marak Squires]

Looks neat, but the license is GPL.

In the faq, it says:

If the GPL doesn't work for your project, get in touch (con...@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:

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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--

-- 

Marak Squires

Co-founder and Chief Evangelist

Nodejitsu, Inc.

marak....@gmail.com

[Bradley Meck]

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

[Joshua Cohen]

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!).

[Chris Rhoden]

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.

--
chrisrhoden

[Chris Rhoden]

On Wed, Apr 11, 2012 at 4:04 AM, Marak Squires <marak....@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 (con...@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)

--
chrisrhoden

[Marak Squires]

*cue 30 responses disagreeing about licensing*

[Jann Horn]

Am Mittwoch, den 11.04.2012, 07:33 -0700 schrieb Marak Squires:
> *cue 30 responses disagreeing about licensing*

I just wanted to ask why you're opposed to the GPL... :D

[john.tiger]

+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.

[rhasson]

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

[Naouak]

Getting access directly to database in my opinion is not a feature but a serious flaw. So many easy exploits doable like that.

I have also concerns about accessibility and SEO.

Naouak, Grade 2 de Kobal.
Site web: http://www.naouak.net

--

[Mark Hahn]

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.

[Chris Rhoden]

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 <ma...@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.

--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--
chrisrhoden

[Matt]

How does Meteor work across a cluster (or local multi-cpu "cluster.js") installation?

Matt.

[Chris]

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."

[alessio_alex]

I don't see any reason why fibers should be in the core. That's just some user preference, not an essential thing for Node.

[Nuno Job]

 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. :)

Nuno

[Dean Landolt]

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.

[Chris Rhoden]

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. 

--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--
chrisrhoden

[Erlend Fagerheim]

Look's like it's MIT now.  http://meteor.com/faq/how-is-meteor-licensed 

[P. Douglas Reeder]

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.

[Jake Verbaten]

Meteor/derby/mojito are bloated leaky abstraction frameworks

node.js is a library to do evented IO in JavaScript. It's simple and generally does not leak it's abstraction.

On Tue, Jul 31, 2012 at 9:46 AM, P. Douglas Reeder <reed...@gmail.com> wrote:

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.