-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add search from registry #6
Comments
it'd be cool to mirror what http://godoc.org/ does (but nicer design obviously). When you first visit a package's url it is fetched, parsed, and the page is generated. So to prime it we would just have to loop through bower / component etc and start hitting urls. Even if we don't go as far as parsing comments since no one agrees on that shit really anyway, but doing on demand makes it easy for someone to "submit" a package, just curl or browse. That's also nicer than the 15m refresh hackyness I originally did for component since it wont have the same GH rate-limiting issues |
That's really sweet I dig that a lot. We can even just let people prime it on their own haha if we wanted after testing a few ourselves, which is just a weirdly amazing feeling |
my biggest mistake was running it on linode hahahah, damn machine kept crapping out on me so I gave up. Definitely has a nice side-effect that a |
Fo shoa, you think it's basically |
For context: segment-boneyard/khaos#41 |
Would love to use that new http resource schema thinking on it too to make the front-end client for it on the website super simple to do, with ripple as well. |
I suppose yeah there's no reason we couldn't use it for other things, especially if we're not parsing source, just using readmes etc to keep it generic. Definitely tons of micro-environments out there. If you want to sketch up a design I'd be down with getting a backend up on versions.io in our ec2. Maybe the right way to approach would be for versions.io to be api-only, keep all the front-end completely abstracted so it can remain branded on duojs.org etc |
API-only sounds good. One thing for us to solve is how and who keeps track of the micro-environments bounds. Is that Duo's job? or does Versions have a concept of "environments" and then anyone can just add new environments as the please kinda? I think you already solved this before. Versions could also have a front-end too probably, at the bare minimum with docs showing how to use the API. Happy to help with a site there when we're ready for it, would have to mess around with different visual design directions when the time comes to see what feels interesting |
yeah each package can live in multiple environments to satisfy the weird cases like this where duo sort of hijacks bower etc. I figured envs would need moderation otherwise we'll just have people being dicks or typos creating new envs haha |
Once we have the simple registry setup, it would be good to add a nice search functionality here so that people can dive in super quickly and be impressed by what all is available. If the registry has a nice HTTP API for the packages it should be super simple to implement client-side.
The text was updated successfully, but these errors were encountered: