cfconcurrent and a bug fix

[marcesher]

This adds CFConcurrent to the index.

In addition, I fixed a bug in the index refresher. It was looking in the wrong location for the local index file

[atuttle]

Nice! Sorry it took me so long to get to this. I blame GH changing the Notification system right at the point in my life when I'm busiest... I had no idea there were a bunch of PRs in here waiting on me!

[atuttle]

Hm, after further inspection the "bug" you fixed was more of a mental one than a code bug. It was looking in the directory that I intended; but I can see why that would be confusing, because that's not where the file exists in a clone of the repo (so if you just clone it to your local machine, then it would be in the index folder, but the code was looking in the cfadmin folder...)

While making this change might seem to make sense at face value, I think it could possibly be a bad thing. Consider:

You clone the git repo directly into your /cfide/administrator folder, and the code is looking for the index file in the ramen/index folder (as you've changed it to do). This will "work", but completely negates the concept of using GitHub as the primary + central repo.

The original way, you would have a copy of the file, but if you wanted to override the GitHub contents, or just stop it from being requested from GitHub for some reason (e.g. work rules), then you would copy the file to the ramen/cfadmin folder.

I'm happy to discuss it further -- maybe one of us will enlighten the other? -- but my current opinion is that the bug fix portion of this should be undone. :)

[marcesher]

Doesn't matter to me, as long as it's clear what I'm supposed to do.

[marcesher]

ok, let's think about it this way:

1) what is the purpose of looking on the local file system after the github check? 2) if you accept the "bug fix", what harm does that cause to users of ramen? 3) if you accept the "bug fix", what harm does that cause to writers of extensions? What harm does it prevent?

Does keeping it the way it is put extra burden on the people who are contributing extensions? Because when I wrote mine, it certainly did, which is why I figured it was a bug since surely I couldn't be expected to write a bit of config, copy the file somewhere else, tweak, copy, tweak, copy, etc until I got it right.

So help me see what I'm missing here.

As a contributor, my main concern is "make it easy for me". As a user of ramen, it'll always be pulling from github anyway so I don't care about what it does after that.

[atuttle]

It currently looks at the file system to decide whether or not to make the request from GitHub at all. I'd the file is found, it just uses what's available there.

The original idea was for places that may want to use the tool, but are leery of allowing the public repo to possibly "put them at risk" because they can't control what's in it. This way they could have their own, possibly trimmed down, possibly entirely custom index. On Aug 11, 2012 7:08 AM, "Marc Esher" notifications@github.com wrote:

ok, let's think about it this way:

1) what is the purpose of looking on the local file system after the github check? 2) if you accept the "bug fix", what harm does that cause to users of ramen? 3) if you accept the "bug fix", what harm does that cause to writers of extensions? What harm does it prevent?

Does keeping it the way it is put extra burden on the people who are contributing extensions? Because when I wrote mine, it certainly did, which is why I figured it was a bug since surely I couldn't be expected to write a bit of config, copy the file somewhere else, tweak, copy, tweak, copy, etc until I got it right.

So help me see what I'm missing here.

As a contributor, my main concern is "make it easy for me". As a user of ramen, it'll always be pulling from github anyway so I don't care about what it does after that.

— Reply to this email directly or view it on GitHubhttps://github.com/CFCommunity/ramen/pull/15#issuecomment-7665963.

[atuttle]

I definitely understand your motive, though; making it easier for developers. The two problems seem somewhat diametrically opposed, though.

I don't know if it would work, but what about creating a symbolic link in the cfadmin folder to the file in the index folder?

Something else I want to explore is an option to get the script from the local FS instead of making an http request. Maybe that would be useful in this scenario too? On Aug 11, 2012 8:18 AM, "Adam Tuttle" adam@fusiongrokker.com wrote:

It currently looks at the file system to decide whether or not to make the request from GitHub at all. I'd the file is found, it just uses what's available there.

The original idea was for places that may want to use the tool, but are leery of allowing the public repo to possibly "put them at risk" because they can't control what's in it. This way they could have their own, possibly trimmed down, possibly entirely custom index. On Aug 11, 2012 7:08 AM, "Marc Esher" notifications@github.com wrote:

ok, let's think about it this way:

1) what is the purpose of looking on the local file system after the github check? 2) if you accept the "bug fix", what harm does that cause to users of ramen? 3) if you accept the "bug fix", what harm does that cause to _writers_of extensions? What harm does it prevent?

Does keeping it the way it is put extra burden on the people who are contributing extensions? Because when I wrote mine, it certainly did, which is why I figured it was a bug since surely I couldn't be expected to write a bit of config, copy the file somewhere else, tweak, copy, tweak, copy, etc until I got it right.

So help me see what I'm missing here.

As a contributor, my main concern is "make it easy for me". As a user of ramen, it'll always be pulling from github anyway so I don't care about what it does after that.

— Reply to this email directly or view it on GitHubhttps://github.com/CFCommunity/ramen/pull/15#issuecomment-7665963.

[marcesher]

Just not sure.

Maybe the simplest solution at first is to create a "developer's guide" with this stuff right at the front, such that it's not confusing and not a surprise. You are very close to this, obviously, having built it. Getting into the head of developers who are completely unfamiliar with the thing, who are flying blind and who just want to get their code into ramen, is your challenge.

it's the whole "explain it like a 5 year old" thing.

On Sat, Aug 11, 2012 at 8:31 AM, Adam Tuttle notifications@github.comwrote:

I definitely understand your motive, though; making it easier for developers. The two problems seem somewhat diametrically opposed, though.

I don't know if it would work, but what about creating a symbolic link in the cfadmin folder to the file in the index folder?

Something else I want to explore is an option to get the script from the local FS instead of making an http request. Maybe that would be useful in this scenario too? On Aug 11, 2012 8:18 AM, "Adam Tuttle" adam@fusiongrokker.com wrote:

It currently looks at the file system to decide whether or not to make the request from GitHub at all. I'd the file is found, it just uses what's available there.

The original idea was for places that may want to use the tool, but are leery of allowing the public repo to possibly "put them at risk" because they can't control what's in it. This way they could have their own, possibly trimmed down, possibly entirely custom index. On Aug 11, 2012 7:08 AM, "Marc Esher" notifications@github.com wrote:

ok, let's think about it this way:

1) what is the purpose of looking on the local file system after the github check? 2) if you accept the "bug fix", what harm does that cause to users of ramen? 3) if you accept the "bug fix", what harm does that cause to _writers_of extensions? What harm does it prevent?

Does keeping it the way it is put extra burden on the people who are contributing extensions? Because when I wrote mine, it certainly did, which is why I figured it was a bug since surely I couldn't be expected to write a bit of config, copy the file somewhere else, tweak, copy, tweak, copy, etc until I got it right.

So help me see what I'm missing here.

As a contributor, my main concern is "make it easy for me". As a user of ramen, it'll always be pulling from github anyway so I don't care about what it does after that.

— Reply to this email directly or view it on GitHub< https://github.com/CFCommunity/ramen/pull/15#issuecomment-7665963>.

— Reply to this email directly or view it on GitHubhttps://github.com/CFCommunity/ramen/pull/15#issuecomment-7666413.

[atuttle]

Well put. I'll try to create a developers guide soon. :)

Marc Esher wrote:

Just not sure.

Maybe the simplest solution at first is to create a "developer's guide" with this stuff right at the front, such that it's not confusing and not a surprise. You are very close to this, obviously, having built it. Getting into the head of developers who are completely unfamiliar with the thing, who are flying blind and who just want to get their code into ramen, is your challenge.

it's the whole "explain it like a 5 year old" thing.

On Sat, Aug 11, 2012 at 8:31 AM, Adam Tuttle notifications@github.comwrote:

I definitely understand your motive, though; making it easier for developers. The two problems seem somewhat diametrically opposed, though.

I don't know if it would work, but what about creating a symbolic link in the cfadmin folder to the file in the index folder?

Something else I want to explore is an option to get the script from the local FS instead of making an http request. Maybe that would be useful in this scenario too? On Aug 11, 2012 8:18 AM, "Adam Tuttle" adam@fusiongrokker.com wrote:

It currently looks at the file system to decide whether or not to make the request from GitHub at all. I'd the file is found, it just uses what's available there.

The original idea was for places that may want to use the tool, but are leery of allowing the public repo to possibly "put them at risk" because they can't control what's in it. This way they could have their own, possibly trimmed down, possibly entirely custom index. On Aug 11, 2012 7:08 AM, "Marc Esher" notifications@github.com wrote:

ok, let's think about it this way:

1) what is the purpose of looking on the local file system after the github check? 2) if you accept the "bug fix", what harm does that cause to users of ramen? 3) if you accept the "bug fix", what harm does that cause to _writers_of extensions? What harm does it prevent?

Does keeping it the way it is put extra burden on the people who are contributing extensions? Because when I wrote mine, it certainly did, which is why I figured it was a bug since surely I couldn't be expected to write a bit of config, copy the file somewhere else, tweak, copy, tweak, copy, etc until I got it right.

So help me see what I'm missing here.

As a contributor, my main concern is "make it easy for me". As a user of ramen, it'll always be pulling from github anyway so I don't care about what it does after that.

— Reply to this email directly or view it on GitHub< https://github.com/CFCommunity/ramen/pull/15#issuecomment-7665963>.

— Reply to this email directly or view it on GitHubhttps://github.com/CFCommunity/ramen/pull/15#issuecomment-7666413.

— Reply to this email directly or view it on GitHub https://github.com/CFCommunity/ramen/pull/15#issuecomment-7676090.