couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From till <klimp...@gmail.com>
Subject Re: Plugin Registry (Was Summary of IRC meeting in #couchdb-meeting)
Date Thu, 14 Nov 2013 19:31:28 GMT


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

> On Thu, Nov 14, 2013 at 1:52 PM, till <klimpong@gmail.com (mailto:klimpong@gmail.com)>
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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message