Promote component project in Readme template.

[timoxley]

Anyone who stumbles onto a component repo, unless they already know what component is, may have a hard time figuring out what this 'component install' thing is and where to get it from. It's made especially bad since the term 'component' is particularly ungoogleable.

Even if the module author manually includes a link, where should they link to? component/component repo? Wiki? FAQ? Original blog post? Later, I assume component.io will be the go to, but even then, people may still link back to the wiki, or worst case (which is also currently the most common case)… not link back at all.

A good way to get some consistency here would be to add such a link to the auto-generated Readme template… which you could make cool by using an image. Which you could make even cooler if it was a dynamic image, e.g.:

This live example displays the current total number of components (updated regularly). Could look sexier or display different info, whatever, just an example. Hacked together code for the image generation here.

At the moment it just links back to the wiki, but I think a smart move would be to not link to the target image/landing page directly, instead embed dynamic urls:

component.io/:repo/:user/component.png component.io/refer/:repo/:user

Initially, every repo and link might go to the same target, but later you could centrally and retroactively control the imagery and link target on the readmes of the entire component swarm, without having to go update each repo. That's kinda cool.

Anyway, the core idea is: embed something in the readme template so any components that use component(1) create will refer traffic back to some place where people can find out the what/why/how of component.

[juliangruber]

We def. need something like this! That's the reason why for some projects I still export a global.

[525c1e21-bd67-4735-ac99-b4b0e5262290]

+1

[buschtoens]

Dynamic images won't work on GitHub, since they cache all images.

But the core idea is very right.

+1

[timoxley]

Ahhh, that's possible. I d assumed dynamic would be cool due to the way Travis CI badges work, perhaps Travis works because caches are flushed on push (I guess?). In that case you could change it to "230+ available" so the number would at least be right at push time, but then having each component reporting different numbers would look more like the value was just random...

Way to be a wet blanket by bringing reality into the discussion... I hate that guy :D

[buschtoens]

Yup, that guy is a real lamo.

But wait... I noticed something odd. Right click on that image and check the source.

Travis' images aren't cached... but components logo is. Could it be that, GitHub only caches non-https images, so that we users don't get that pesky warning? I think so, because Travis' build status is delivered via https, whereas the component logo was originally delivered via http.

Test: an image delivered via https. Image url should be: https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcRsG464cF1uZXfhJ4w38Zr28u1pNbWeJ1lsoROw2yQRAkPr0tBO8Q

[buschtoens]

Yup. works! We can use the dynamic images if they are delivered via https.

[timoxley]

Good detective work. I had a brief look for some documentation on this feature but came up dry.

[525c1e21-bd67-4735-ac99-b4b0e5262290]

I just had a rather thorough look through markup, redcarpet, sundown and could not find a single reference to caching, or any real difference in http/https for that matter.

There are, however, references to this behaviour in publications by Akamai; the CDN fronting GitHub.

[weepy]

it's because if they link to a http image from a page that's https ---- it will break the security of the page.

On Thu, Nov 8, 2012 at 4:18 PM, Nicholas Kinsey notifications@github.comwrote:

I just had a rather thorough look through markuphttps://github.com/github/markup, redcarpet https://github.com/vmg/redcarpet, sundownhttps://github.com/vmg/sundownand could not find a single reference to caching.

There are, however, references in publications by Akamaihttp://www.akamai.com/dl/feature_sheets/fs_edgesuite_securecontentdelivery.pdf .

— Reply to this email directly or view it on GitHubhttps://github.com/component/component/issues/144#issuecomment-10193880.

[525c1e21-bd67-4735-ac99-b4b0e5262290]

@weepy it's because if they link to a http image from a page that's https ---- it will break the security of the page.

Indeed, as @silvinci mentioned in his comment:

Travis' images aren't cached... but components logo is. Could it be that, GitHub only caches non-https images, so that we users don't get that pesky warning? I think so, because Travis' build status is delivered via https, whereas the component logo was originally delivered via http.

The question remains: does it simply proxy the asset to avoid mixing protocols or, more complexly, does it also cache them during this process for some substantial amount of time too?

If not, awesome. Let it proxy.

If so, for how long? Can it be bypassed or limited?

[buschtoens]

When this dot becomes green anytime soon they recache. I changed the original resource to a green dot.

Do they recache on edits?

[525c1e21-bd67-4735-ac99-b4b0e5262290]

Green from here in both the email notification and from the site too :)

[buschtoens]

Yup, I edited the post to test. Seems like they recache on edits.

[buschtoens]

I won't edit this post. Let's see, if it becomes green.

[525c1e21-bd67-4735-ac99-b4b0e5262290]

Looks like camo is the proxy. Yet that's still all behind akamai.

Layers. Onions have layers.

[buschtoens]

Awesome. So that means, we don't have to purchase a SSL certificate. Haha. :)

[buschtoens]

Oh great, @guille already owns component.io. :D

[525c1e21-bd67-4735-ac99-b4b0e5262290]

Thank you for your Sherlock Holmes-calibre investigative insights @silvinci

I've wanted to probe deeper into this kind of thing in the pursuit of the elusive, dynamic README.

The latest test is still red for me; I suspect it will remain that way until an edit but I'll keep watch.

[buschtoens]

Delete your browser cache. (Ctrl + F5)

[525c1e21-bd67-4735-ac99-b4b0e5262290]

Still red. I'm hopeful for some kind of polling sorcery.

Nevertheless, having to bump the README isn't the end of the world.

Consider it an incentive to keep it maintained.

[buschtoens]

That's really weird, because me it's green for me. Hm, GitHub works in mysterious (but pretty awesome) ways. I'll do a quick README.md test...

[525c1e21-bd67-4735-ac99-b4b0e5262290]

It's definitely still red from here (iiNet, Australia).

As I understand, Akamai practises all manner of witchcraft against space-time.

Nothing is immune to the uncertainty principle ^w^

[buschtoens]

Let's see how it performs in README.md.

https://github.com/silvinci/readme-test I'll change the image in about 5 minutes, without pushing to the master.

Haha, you got me with the uncertainty principle. :D

[tj]

awesome idea! at very worst if we cant get that going a link is definitely a must

[buschtoens]

I changed the image resource and it's still red. Deleting the cache doesn't work either (my iPhone shows red too). Guess, we'll have to wait and see when (and if) camo recaches.

[525c1e21-bd67-4735-ac99-b4b0e5262290]

Schrödinger's Cache

[buschtoens]

Schrödinger's cache! HAHA, I'm choking on my coke. :laughing:

[525c1e21-bd67-4735-ac99-b4b0e5262290]

We have liftoff.

I repeat; we have liftoff.

[buschtoens]

I correct, we may have or may not have liftoff.

For me it's still red. But It's plain to see, that GitHub recaches, so green lights for dynamic images. :smile:

[525c1e21-bd67-4735-ac99-b4b0e5262290]

Caching! Caching, Jan, you boy. Drained dry. I'm so sorry. Here, if you have an image, and I have an image, and I have a CDN. There it is, that's a CDN, you see? You watching?. And my CDN, reaches, acroooooooss the internet, and starts to cache your image... I... cache... your... image!

I CACHE IT UP!

[buschtoens]

2012: an internet odyssey.

Okay, btt. I would prefer this:

[![This is a component](http://www.component.io/refer/:user/:repo.png)](http://www.component.io/components/:user/:repo)

We could also add some GET parameters so the image is somewhat configurable.

[juliangruber]

wtf is this sorcery! if it works for travis it will work for component and having the cound even days behind should never be a problem

[525c1e21-bd67-4735-ac99-b4b0e5262290]

if it works for travis it will work for component

This presumes

• GitHub isn't making an exception for Travis
• We don't want to make the effort to keep the counters as fresh as possible
• We don't want some other, perhaps even more dynamic, information in the badges

[tj]

maybe github is respecting:

Cache-Control: private
Content-Disposition: inline; filename="passing.png"

[525c1e21-bd67-4735-ac99-b4b0e5262290]

@visionmedia maybe github is respecting:

Cache-Control: private Content-Disposition: inline; filename="passing.png"

Good call. Naturally, Akamai seems vastly configurable WRT all of this.

@silvinci Perhaps more insightful than using gh-pages would be something we can get at the logs of.

If only we had a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications, using an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

[buschtoens]

Green for me too now. We don't have to worry about GitHub's/Akamai's caching methods anymore. Although it would be pretty cool, if GitHub is respecting Cache-Control: private.

So what about the proposed format? Should plain text be added? Should additional text be added in the image?
I kinda like @timoxley's image. But others may prefer bigger, more descriptive images. These could include text about components or the component itself. Could be configured with /:repo.png?description&someMoreStuff&andThatTooPlease.

@pyrotechnick Ah, let's build it and name it PHP (lol).

The only problem is that not all requests are forwarded to component.io. But it would still be interesting and we could nag authors, who don't have implemented the image yet.

Automated PRs? :heart:

[yields]

If only we had a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications, using an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

That would be awesome :)

[ForbesLindesay]

Awesome work guys. I love this idea. I'm happy to extend the component.jit.su website to serve this image. I'm also happy to set it up with a landing page route that redirects somewhere sensible. I think if we're doing that it's probably time we made it the official component.io website as it's probably better than nothing. P.S. "component.io" will hopefully be much more google able than "component"

[ForbesLindesay]

Component badge is now available as a dynamic badge (updated every 15 minutes) at https://component.jit.su/component-badge.svg

At time of writing that's 348 available components, but it should update every 15 minutes.

[gjohnson]

Awesome!

[ForbesLindesay]

The biggest thing now is to try and get #189 sorted

[timoxley]

Whoo. Nice one guys.

[buschtoens]

10 hours passed an we've gone from 348 to 350. What a satisfying feeling. :+1:

[tj]

hahaha sexay. I'm excited to see the graphs in a few months from now we're going pretty steady, seems to be around 3-5 per day

[tj]

not sure why my count says {"count":328,"timestamp":1354602373311,"authors":56}

[buschtoens]

We have a custom parser. Probably something's going wrong there. I'll implement yours in about 8 hours (school).

Do you got news on GitHub's improved searching API?

[buschtoens]

Did a quick <li> count on the wiki. We have 350 components indeed.

Do you already have a graph on components growth? ForbesLindesay/component-website#14

[tj]

hmm some of the must not be getting into redis due to errors or something, because it shows we have less, do component search | grep url | wc -l. Yup I have graphs already

[tj]

closing now that we have the badge, we could add a wiki page with some Media links for logos/badges/etc

[ForbesLindesay]

Would it not make sense to include the badge in the default readme template? I don't think we do that yet...

It would need to wait for the new website as I'll want to take component.jit.su down a month or so after the real site goes live.