Skip to content
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

Open
ianstormtaylor opened this issue Aug 18, 2014 · 9 comments
Open

add search from registry #6

ianstormtaylor opened this issue Aug 18, 2014 · 9 comments

Comments

@ianstormtaylor
Copy link
Contributor

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.

@tj
Copy link

tj commented Aug 22, 2014

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

@ianstormtaylor
Copy link
Contributor Author

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

@tj
Copy link

tj commented Aug 22, 2014

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 duo-submit (or whatever) could just send a request and boom that's it

@ianstormtaylor
Copy link
Contributor Author

Fo shoa, you think it's basically versions.io? or at least the beginning of something that could turn into it?

@ianstormtaylor
Copy link
Contributor Author

For context: segment-boneyard/khaos#41

@ianstormtaylor
Copy link
Contributor Author

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.

@tj
Copy link

tj commented Aug 22, 2014

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

@ianstormtaylor
Copy link
Contributor Author

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

@tj
Copy link

tj commented Aug 23, 2014

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants