registry optimize idea

[vision media [ Tj Holowaychuk ]]

simple idea but I wanted to get some feedback. now that I'm crawling around in npm I'm realizing how much it could gain from optimizing on the server side for dep resolution. I was thinking the client wouldn't ask for a semver version of a package, the client would send the entire dep tree, it gets fully resolved on the server & not a single dupliate in-flight request occurs.

Npm's way of dealing with this isn't as eager so it's not only really complicating client code but wasting network traffic, and from the resolving point of view there's a bunch of hacky non-eager crawling to see if the parent has the dep yet etc. Curious for feedback but I think this would be a lot more elegant 

[Jonathan Ong]

this is what i wanted before and was waiting to rework component, but i realized that component should work without the registry anyways. 

this would basically be a resolver.js server, which would be pretty easy to do. caching already works when downloading locally. a "registry" would just be a resolver.js server back by a different remote (a db for storing versions and git trees, s3 for storing the actual local components).

but i think these two should remain separate. the main registry should just consolidate git/gitorious/bitbucket and maybe npm APIs. the actual resolution and serving can be done by a resolver.js server.

[vision media [ Tj Holowaychuk ]]

most of the registry I'm building as if component etc doesn't even exist conceptually really. I don't want to tailor it to any one platform specifically, we want this thing to completely clobber rubygems/npm/etc, so it has to be built in a way that is agnostic, so anything to clean up client implementations really helps there as well. I'm not 100% on this part but I do think most forms of caching for package management are codesmell, it should be robust and fast without

--
You received this message because you are subscribed to the Google Groups "component" group.
To unsubscribe from this group and stop receiving emails from it, send an email to componentjs...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jonathan Ong]

also the registry would be a github/npm/bitbucket, etc. mirror. or it could link clients to mirrors or something. we don't want to be at the mercy of any single person's servers *COUGH* NPM *COUGH*

[vision media [ Tj Holowaychuk ]]

that part is easy, it really wouldn't be hard to be much much more stable that npm, especially leveraging s3, our servers would be doing almost nothing, just basic book-keeping so I'm not worried about that. I DONT want distributed packages because then you just have multiple points of failure, I know that sounds odd and better haha, but that's only better if they have similar robustness properties or replicate the data. That's a huge problem with Go code right now, some is on github, some is on personal sites, blah blah, huge mess

--

[vision media [ Tj Holowaychuk ]]

just realized I made the subject "optimize idea" haha.. engrish fail

[William Casarin]

Yeah as long as its easy to run a mirror that would be fine. No need to have your dependencies reference specific locations like you said, except for private repo use cases perhaps.