81–90 of 350 posts
Looks nice. There are a handful of similar frameworks out there (e.g now.js http://nowjs.com/ , socketstream https://github.com/socketstream/socketstream )...the trend seems to be toward heavy use of sockets in webapps. I'm developing with socketstream right now, and I love it. I hope they are all successful.
This is a very uncool way to install something: $ curl install.meteor.com | /bin/sh
I am to blame for that. Here is our thinking on it: - Though it "feels wrong" (definitely with you there), is it really any different from downloading an installer package and running it? - You can just go to install.meteor.com in your browser if you want to see what the script does (or just leave off the | sh), which is arguably better than other installation mechanisms. Curious to hear people's thoughts :)
I will also admit to disagreeing with the poster suggesting that it should all go to ~/.meteor. I kind of hate that type of install... at least when I don't have an option. I don't want to install it multiple times for different users, and I don't like "system" software in my home directory, I like to keep my user data there and back it up more regularly that /usr/local which is all things I can reinstall in case of disaster.
I guess the ideal would be to ask the user.
Comment...
# add to $PATH
mkdir -p "$PARENT/bin"
rm -f "$PARENT/bin/meteor"
ln -s "$TARGET/bin/meteor" "$PARENT/bin/meteor"
Earlier quoted context omitted.
I am to blame for that. Here is our thinking on it: - Though it "feels wrong" (definitely with you there), is it really any different from downloading an installer package and running it? - You can just go to install.meteor.com in your browser if you want to see what the script does (or just leave off the | sh), which is arguably better than other installation mechanisms. Curious to hear people's thoughts :)
I'm chiming in here because it may still be early enough to stop you. Do. Not. Require. Root. Not optionally, not sometimes, not "maybe". NEVER. Your universe is ~/.meteor. Do not even think about touching anything outside that. It's taboo. You clearly know what you're doing otherwise, so please get this one right from the start and save yourselves a lot of headache later on (cf. npm). Install to ~/.meteor and provid…
I'm sure you have good reasons, I just can't see them here.
This feels to me a lot like how Rails felt back in 2005. A fundamental leap forward and an understanding of where web technology is going. I haven't felt that way about Node.js or even its higher-level frameworks like Express or Batman. This feels like "The One", even though I've been absorbing the docs and screencasts only for the last 20 minutes.
Completely agree. I thought Backbone was the "missing piece", but this really is it. Edit: to clarify I specifically meant a front-end tool to help me leap a level in personal development skill.
Freaking love the name too (admittedly a non-trivial factor to me when deciding whether to investigate new technologies).
For us it needs to support our live data feeds, inter-operate nicely with our PostgreSQL db (via our own API?) and if possible take advantage of our existing django application.
Our rendered dashboards need to be seamless and fast. I've been leaning towards highly cached static data to ensure this.
Earlier quoted context omitted.
I'm chiming in here because it may still be early enough to stop you. Do. Not. Require. Root. Not optionally, not sometimes, not "maybe". NEVER. Your universe is ~/.meteor. Do not even think about touching anything outside that. It's taboo. You clearly know what you're doing otherwise, so please get this one right from the start and save yourselves a lot of headache later on (cf. npm). Install to ~/.meteor and provid…
It would be more helpful for people reading this comment if you gave reasons beyond "It's taboo". I'm sure you have good reasons, I just can't see them here.
To illustrate, a few simple questions:
What if I need multiple meteor versions on the same system (different versions for different users/projects)?
How do I quickly switch between different meteor versions (often needed in fast-moving projects like this)?
How do I monkey-patch meteor to try something out and/or contribute back?
What if I absolutely must mix meteor with an unsupported version of node or other runtime dependency?
What if all my servers are SuSE Solaris95 but you only provide packages for Debian and RedHat?
How do I bundle my meteor runtime with my deployment?
Is GPL really viable for a web framework? The Free Software Foundation has consistently held that linking to GPL code (not LGPL) is derived work.
I think Meteor actually has the opposite problem: Running a web app is not generally considered to be distribution, so as long as you aren't actually giving the source code to anybody else, the requirements of the GPL don't apply to you. (IANAL, but this is my understanding.)
Earlier quoted context omitted.
Right. But as soon as you have this ability, don't you quickly turn off insert/update? then you throttle/contain reads... So in the end, do we benefit from having a client side database connection? I'm struggling to put together a real-world use case for one that isn't irresponsible.
On the "read" side of things, you control what data is exposed to each subscription, and you'll be able to base access on authentication. The client doesn't get a direct database connection, but rather a live-updating subset (or arbitrary function, in the general case) of the database. The rationale is that clients typically end up doing sorting and filtering on subsets of the database anyway, as they get more sophis…
There would need to be some sort of public key system for authentication, but in the end you are still compromising your data if the client gets hacked. There would have to be a database control layer for the final say, and thats called a server.