no such package: inject initial

[ghost]

Just installed from repo, will not meteor add or mrt add.

[gadicc]

Sorry about that, guess I should make these kind of changes on a separate devel branch. I'll do that in future. You have 2 options (either will work):

1) You can also install inject-initial from https://github.com/gadicc/meteor-inject-initial

2) You can roll back one commit in meteor-headers to 712d0ff43f4d5e3549ccd1a844c298645fb5b2a4

Curious though why, if you're using mrt, you're taking on all the extra work of installing and maintaining packages by hand?

[gadicc]

Uh wait, also, your first comment, are you talking about meteor-headers or inject-initial?

mrt add headers works fine, that's the last official release.

inject-initial isn't released yet. you'll only need it if you're also using an unreleased version of meteor-headers from the repo. it will be released soon (the same time as the next official release of meteor-headers).

[ghost]

i searched for inject but not on github, doh! sometimes mrt fails me (specifically w/iron-router), in this instance i took to the hand install with meteor-headers because the inject dependency caused mrt to fail. thanks!

On Sun, Mar 23, 2014 at 12:36 AM, Gadi Cohen notifications@github.comwrote:

Uh wait, also, your first comment, are you talking about meteor-headers or inject-initial?

Reply to this email directly or view it on GitHubhttps://github.com/gadicc/meteor-headers/issues/24#issuecomment-38373931 .

[gadicc]

Ok, glad you're up! Yeah sorry, I really should make changes like this to a devel branch, but most of our users install via mrt (which definitely still works, I double checked now). inject-initial is a new package (written yesterday), just waiting for some feedback on it before it becomes official, in case any API changes are needed.

P.S. For most of those mrt/iron-router problem you can usually just run mrt with --force.

[ghost]

Thanks for the tip! Now that I think about it, I believe that I found your project by Firefoxing for "meteor get client ip" not thinking that I would need a whole mess of code to get it, lol. Coming from a PHP background it's just sort of always there.. I had not thought of searching Atmosphere.

To digress a bit, the whole Meteor experience is changing my workflow and methodology quite a bit. I haven't used anyone else's code in combination with my own ever, so my first inclination is always to Google up a quick code reference rather than a whole package of code.

Thanks a lot for being so responsive!

On Sun, Mar 23, 2014 at 1:00 AM, Gadi Cohen notifications@github.comwrote:

Ok, glad you're up! Yeah sorry, I really should make changes like this to a devel branch, but most of our users install via mrt (which definitely still works, I double checked now). inject-initial is a new package (written yesterday), just waiting for some feedback on it before it becomes official, in case any API changes are needed.

P.S. For most of those mrt/iron-router problem you can usually just run mrt with --force.

Reply to this email directly or view it on GitHubhttps://github.com/gadicc/meteor-headers/issues/24#issuecomment-38374309 .

[gadicc]

Haha sure. I came from the same background, and it's actually been awesome to be able to so easily add external code that's well packaged not to break anything. Definitely get familiar with Atmosphere... the upcoming version is super cool :) You can save sooooo much time by relying on (and supporting) community work.

Note, since Meteor 0.7.2, you can use this.connection.clientAddress from Meteor directly in publish/methods (i.e. on the server). This is the IP initiating the DDP connection. meteor-headers of course let's you also access the initial HTTP connection headers (which are a bit more detailed than the heades in the XHR request, although less relevant for client IP), and makes them conveniently accessible on the client-side too.

[ghost]

Yes, that is something I was working on in my CMS for a long time, was proper packaging. This comes very close to my final solution in face, I had always kept my server side code in _public_html and only put styling code and a basic site loader in public_html proper.

I appreciate what you're saying about community work. I always held my code like an awesome poker hand, I never wanted it to be used against me by local competitors but that was probably a non-issue in retrospect. All that I would have gained by sharing would have far superseded any local competition. I will OSS all my personal work forever more. :D It helps that the world has changed so much the past few years and GIthub is so awesome. ;>

Excellent tip on the clientAddress info. TBH, I usually start with reading docs from beginning to end but in this case I have started with Discovering Meteor (finished it cpl days ago), but reading docs.meteor from top to bottom is next.

I'm glad you mentioned that it was the IP initiating the DDP connection as I briefly saw something alluding to that difference the other day and intended to research it further when building an upcoming package for Atmosphere.

As I do enjoy parsing HTTP headers, I intend to follow and use your project, so... thank you again! :D

On Sun, Mar 23, 2014 at 2:11 AM, Gadi Cohen notifications@github.comwrote:

Haha sure. I came from the same background, and it's actually been awesome to be able to so easily add external code that's well packaged not to break anything. Definitely get familiar with Atmosphere... the upcoming versionhttp://beta.atmospherejs.com/is super cool :) You can save sooooo much time by relying on (and supporting) community work.

Note, since Meteor 0.7.2, you can use this.connection.clientAddress from Meteor directly in publish/methods (i.e. on the server). This is the IP initiating the DDP connection. meteor-headers of course let's you also access the initial HTTP connection headers (which are a bit more detailed than the heades in the XHR request, although less relevant for client IP), and makes them conveniently accessible on the client-side too.

Reply to this email directly or view it on GitHubhttps://github.com/gadicc/meteor-headers/issues/24#issuecomment-38375122 .

[gadicc]

Sure. I definitely hear you, and used to think the same, but at the end of the day, you get a big benefit from having the code that's not directly related to your project contributed as open source. It's great to get problems in this underlying code (which you might share between of a few of your projects) solved by others before it ever becomes a problem for you personally, and likewise for improvements before you need them. Additionally, you get this benefit for all other useful packages in the public domain which can save you an incredible amount of time in development.

Believe me, I also used to do everything myself, but with powerful packaging like in Meteor (with separate namespacing for each package, easily installation, etc) and open code collaboration sites like github (as you pointed out), it's a whole new world :) As for competitors, I'm waiting for the day when a client says "oh yeah but your competitor's site also does that" and I'm like "look, do you want the guys who can use my code, or the guy who actually wrote it?" :)

[ghost]

Excellent points all, good sir! Thanks! :D

BTW, this is the code I ended up writing to get the heading info I desired.. https://gist.github.com/arthax0r/9780849#file-get-headers-js

On Thu, Mar 27, 2014 at 7:03 AM, Gadi Cohen notifications@github.comwrote:

Sure. I definitely hear you, and used to think the same, but at the end of the day, you get a big benefit from having the code that's not directly related to your project contributed as open source. It's great to get problems in this underlying code (which you might share between of a few of your projects) solved by others before it ever becomes a problem for you personally, and likewise for improvements before you need them. Additionally, you get this benefit for all other useful packages in the public domain which can save you an incredible amount of time in development.

Believe me, I also used to do everything myself, but with powerful packaging like in Meteor (with separate namespacing for each package, easily installation, etc) and open code collaboration sites like github (as you pointed out), it's a whole new world :) As for competitors, I'm waiting for the day when a client says "oh yeah but your competitor's site also does that" and I'm like "look, do you want the guys who can use my code, or the guy who actually wrote it?" :)

Reply to this email directly or view it on GitHubhttps://github.com/gadicc/meteor-headers/issues/24#issuecomment-38790083 .