On Thursday 14 November 2013 at 20:15, Brian Mitchell wrote:

> On Thu, Nov 14, 2013 at 1:52 PM, till <[email protected] 
> (mailto:[email protected])> wrote:
> > On Thursday 14 November 2013 at 18:28, Simon Metson wrote:
> > >  
> > > I’m interested in this too. Can we pick up stuff from npm?
> > > Cheers
> > > Simon
> > >  
> >  
> >  
> > Please don’t. For starters, a more or less static registry would be 
> > awesome. Not databased.
>  
> I'm curious how static really avoids the database problem. Are you
> saying it'd be better to just pull down a know good URL and that never
> changes?
>  
>  

Should have elaborate on this more.

For NPM, I’d like to see them move in a direction where I can mirror it on a 
static host or CDN vs. something that requires a database server. :-) CouchDB 
replication is amazing but correct me if I am wrong, but rsync is a great tool 
to mirror A to B. :-) CouchDB should still be the backend, but an in between 
step to be able to dump static files from it would be awesome.

I totally see the dogfood appeal as well. ;-)  
>  
> Beyond that, I'm not sure we need to use CouchDB just like NPM does
> but it is pretty nice. Maybe fewer document mutations would help
> (splitting plugin releases into their own documents could be a good
> idea for those running local mirrors).
>  
> > Then minor nitpicks like:
> >  
> (…)
> > - don’t allow people to re-upload releases
>  
>  
> Yes. We could avoid this partly by making releases more like immutable
> documents.
>  
>  

Yup — that also requires a little more brainpower than a github crawler.  
>  
> > - make it easy to mirror it
>  
> Replication is a natural fit here. There might be an argument for
> allowing automated installation via plain-old-HTTP or filesystem
> mirrors as well for the cases where people don't want to have to have
> a separate database running just to setup their own CouchDB nodes with
> private plugins (chicken-egg like situations emerge).
>  
>  

Yeah, see my response above.

I can see the approach — my goal would be to enable people to host on Amazon S3 
in the end. :-) E.g. local CouchDB on the LAN, dump/export to a bucket on 
Amazon S3/Cloudfiles/whatever.

Then, all of a sudden — highly available infrastructure. ;-)

Till

Reply via email to