You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Brian Mitchell <br...@strmpnk.co> on 2013/11/14 17:33:01 UTC
Plugin Registry (Was Summary of IRC meeting in #couchdb-meeting)
> >> # 4. plans for 1.6 release #
> >> 19:15:31 [Kxepal]: btw. any plans for 1.6 release?
> >> 19:15:46 [awenkhh]: when is 1.6 release scheduled for?
> >> 19:15:46 [Kxepal]: one feature we have: stable Fauxton and replacement
> >> Futon withit. any other goals?
> >> 19:16:37 [Kxepal]: awenkhh: theoretically, there is release per one
> >> month schedule, but practically month or two
> >> 19:16:57 [Kxepal]: so it might be "holidays" release
> >> 19:17:04 [awenkhh]: ;-)
> >> 19:17:04 [Humbedooh]: a christmas couch :)
> >> 19:17:18 [Kxepal]: yea!
> >> 19:17:18 [Humbedooh]: Manger 1.6
> >> 19:17:18 [nslater]: awenkhh: we should kick it off in one month
> >> 19:17:25 [nslater]: but completing it may take longer because hols
> >> 19:17:34 [jan____]: I’d like to work more on plugins and get the node
> >> query server improved
> >
> > Should have this somewhere here:
> >> 19:22:46 [strmpnk]: jan____: any milestones for that in mind or just
> >> general progress?
> >
> > I do think we should make sure experimental code doesn’t dwindle in the tree, not that these new additions are at all old. Having some intermediate milestones before we make these things stable would be interesting.
> >
> > For the plugins, it’d be good to have some contributed plugins users can easily activate to test the system.
>
> I agree, src/couch_plugins/README.md has a quasi roadmap that I want to work
> towards. The only edit for now would be that I’d like a registry that can be
> update independently from CouchDB releases. Would you be interested in helping
> out with that? Or anything else around plugins?
I'm definitely interested to hear more. I'd love to help out with
getting a common place for contributed couchdb things to be indexed
and published. Plugins seem like an ideal testing ground. How do you
imagine a plugin registry working?
Re: Plugin Registry (Was Summary of IRC meeting in #couchdb-meeting)
Posted by Jan Lehnardt <ja...@apache.org>.
On 05 Jan 2014, at 12:09 , Hans J Schroeder <hs...@cloudno.de> wrote:
> I recently tried the new plugin system. It is a great feature. But I guess
> something needs to be done with the version checking. Checksums are too
> restrictive. Actually I couldn't install any plugin, although it would run,
> for instance geocouch 1.3 on CouchDB 1.5. With the current pace of
> releasing CouchDBs, Devs would also be forced to update all their plugins
> at the same pace. NPM is much more flexible with regard to versioning.
Excellent point. I filed https://issues.apache.org/jira/browse/COUCHDB-2023
Best
Jan
--
>
> - Hans
>
>
> On Sat, Jan 4, 2014 at 10:25 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>> On 14 Nov 2013, at 17:33 , Brian Mitchell <br...@strmpnk.co> wrote:
>>
>>>>>> # 4. plans for 1.6 release #
>>>>>> 19:15:31 [Kxepal]: btw. any plans for 1.6 release?
>>>>>> 19:15:46 [awenkhh]: when is 1.6 release scheduled for?
>>>>>> 19:15:46 [Kxepal]: one feature we have: stable Fauxton and replacement
>>>>>> Futon withit. any other goals?
>>>>>> 19:16:37 [Kxepal]: awenkhh: theoretically, there is release per one
>>>>>> month schedule, but practically month or two
>>>>>> 19:16:57 [Kxepal]: so it might be "holidays" release
>>>>>> 19:17:04 [awenkhh]: ;-)
>>>>>> 19:17:04 [Humbedooh]: a christmas couch :)
>>>>>> 19:17:18 [Kxepal]: yea!
>>>>>> 19:17:18 [Humbedooh]: Manger 1.6
>>>>>> 19:17:18 [nslater]: awenkhh: we should kick it off in one month
>>>>>> 19:17:25 [nslater]: but completing it may take longer because hols
>>>>>> 19:17:34 [jan____]: I’d like to work more on plugins and get the node
>>>>>> query server improved
>>>>>
>>>>> Should have this somewhere here:
>>>>>> 19:22:46 [strmpnk]: jan____: any milestones for that in mind or just
>>>>>> general progress?
>>>>>
>>>>> I do think we should make sure experimental code doesn’t dwindle in
>> the tree, not that these new additions are at all old. Having some
>> intermediate milestones before we make these things stable would be
>> interesting.
>>>>>
>>>>> For the plugins, it’d be good to have some contributed plugins users
>> can easily activate to test the system.
>>>>
>>>> I agree, src/couch_plugins/README.md has a quasi roadmap that I want to
>> work
>>>> towards. The only edit for now would be that I’d like a registry that
>> can be
>>>> update independently from CouchDB releases. Would you be interested in
>> helping
>>>> out with that? Or anything else around plugins?
>>>
>>> I'm definitely interested to hear more. I'd love to help out with
>>> getting a common place for contributed couchdb things to be indexed
>>> and published. Plugins seem like an ideal testing ground. How do you
>>> imagine a plugin registry working?
>>
>> I’ve filed a JIRA issue here:
>>
>> https://issues.apache.org/jira/browse/COUCHDB-2015
>>
>> (and more for plugins at
>> https://issues.apache.org/jira/browse/COUCHDB-2015?jql=component%20%3D%20Plugins%20AND%20project%20%3D%20COUCHDB%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC
>> )
>>
Re: Plugin Registry (Was Summary of IRC meeting in #couchdb-meeting)
Posted by Hans J Schroeder <hs...@cloudno.de>.
I recently tried the new plugin system. It is a great feature. But I guess
something needs to be done with the version checking. Checksums are too
restrictive. Actually I couldn't install any plugin, although it would run,
for instance geocouch 1.3 on CouchDB 1.5. With the current pace of
releasing CouchDBs, Devs would also be forced to update all their plugins
at the same pace. NPM is much more flexible with regard to versioning.
- Hans
On Sat, Jan 4, 2014 at 10:25 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On 14 Nov 2013, at 17:33 , Brian Mitchell <br...@strmpnk.co> wrote:
>
> >>>> # 4. plans for 1.6 release #
> >>>> 19:15:31 [Kxepal]: btw. any plans for 1.6 release?
> >>>> 19:15:46 [awenkhh]: when is 1.6 release scheduled for?
> >>>> 19:15:46 [Kxepal]: one feature we have: stable Fauxton and replacement
> >>>> Futon withit. any other goals?
> >>>> 19:16:37 [Kxepal]: awenkhh: theoretically, there is release per one
> >>>> month schedule, but practically month or two
> >>>> 19:16:57 [Kxepal]: so it might be "holidays" release
> >>>> 19:17:04 [awenkhh]: ;-)
> >>>> 19:17:04 [Humbedooh]: a christmas couch :)
> >>>> 19:17:18 [Kxepal]: yea!
> >>>> 19:17:18 [Humbedooh]: Manger 1.6
> >>>> 19:17:18 [nslater]: awenkhh: we should kick it off in one month
> >>>> 19:17:25 [nslater]: but completing it may take longer because hols
> >>>> 19:17:34 [jan____]: I’d like to work more on plugins and get the node
> >>>> query server improved
> >>>
> >>> Should have this somewhere here:
> >>>> 19:22:46 [strmpnk]: jan____: any milestones for that in mind or just
> >>>> general progress?
> >>>
> >>> I do think we should make sure experimental code doesn’t dwindle in
> the tree, not that these new additions are at all old. Having some
> intermediate milestones before we make these things stable would be
> interesting.
> >>>
> >>> For the plugins, it’d be good to have some contributed plugins users
> can easily activate to test the system.
> >>
> >> I agree, src/couch_plugins/README.md has a quasi roadmap that I want to
> work
> >> towards. The only edit for now would be that I’d like a registry that
> can be
> >> update independently from CouchDB releases. Would you be interested in
> helping
> >> out with that? Or anything else around plugins?
> >
> > I'm definitely interested to hear more. I'd love to help out with
> > getting a common place for contributed couchdb things to be indexed
> > and published. Plugins seem like an ideal testing ground. How do you
> > imagine a plugin registry working?
>
> I’ve filed a JIRA issue here:
>
> https://issues.apache.org/jira/browse/COUCHDB-2015
>
> (and more for plugins at
> https://issues.apache.org/jira/browse/COUCHDB-2015?jql=component%20%3D%20Plugins%20AND%20project%20%3D%20COUCHDB%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC
> )
>
Re: Plugin Registry (Was Summary of IRC meeting in #couchdb-meeting)
Posted by Jan Lehnardt <ja...@apache.org>.
On 14 Nov 2013, at 17:33 , Brian Mitchell <br...@strmpnk.co> wrote:
>>>> # 4. plans for 1.6 release #
>>>> 19:15:31 [Kxepal]: btw. any plans for 1.6 release?
>>>> 19:15:46 [awenkhh]: when is 1.6 release scheduled for?
>>>> 19:15:46 [Kxepal]: one feature we have: stable Fauxton and replacement
>>>> Futon withit. any other goals?
>>>> 19:16:37 [Kxepal]: awenkhh: theoretically, there is release per one
>>>> month schedule, but practically month or two
>>>> 19:16:57 [Kxepal]: so it might be "holidays" release
>>>> 19:17:04 [awenkhh]: ;-)
>>>> 19:17:04 [Humbedooh]: a christmas couch :)
>>>> 19:17:18 [Kxepal]: yea!
>>>> 19:17:18 [Humbedooh]: Manger 1.6
>>>> 19:17:18 [nslater]: awenkhh: we should kick it off in one month
>>>> 19:17:25 [nslater]: but completing it may take longer because hols
>>>> 19:17:34 [jan____]: I’d like to work more on plugins and get the node
>>>> query server improved
>>>
>>> Should have this somewhere here:
>>>> 19:22:46 [strmpnk]: jan____: any milestones for that in mind or just
>>>> general progress?
>>>
>>> I do think we should make sure experimental code doesn’t dwindle in the tree, not that these new additions are at all old. Having some intermediate milestones before we make these things stable would be interesting.
>>>
>>> For the plugins, it’d be good to have some contributed plugins users can easily activate to test the system.
>>
>> I agree, src/couch_plugins/README.md has a quasi roadmap that I want to work
>> towards. The only edit for now would be that I’d like a registry that can be
>> update independently from CouchDB releases. Would you be interested in helping
>> out with that? Or anything else around plugins?
>
> I'm definitely interested to hear more. I'd love to help out with
> getting a common place for contributed couchdb things to be indexed
> and published. Plugins seem like an ideal testing ground. How do you
> imagine a plugin registry working?
I’ve filed a JIRA issue here:
https://issues.apache.org/jira/browse/COUCHDB-2015
(and more for plugins at https://issues.apache.org/jira/browse/COUCHDB-2015?jql=component%20%3D%20Plugins%20AND%20project%20%3D%20COUCHDB%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC)
Re: Plugin Registry (Was Summary of IRC meeting in
#couchdb-meeting)
Posted by Dave Cottlehuber <dc...@jsonified.com>.
On 14. November 2013 at 17:33:35, Brian Mitchell (brian@strmpnk.co) wrote:
> users can easily activate to test the system.
> >
> > I agree, src/couch_plugins/README.md has a quasi roadmap
> that I want to work
> > towards. The only edit for now would be that I’d like a registry
> that can be
> > update independently from CouchDB releases. Would you be interested
> in helping
> > out with that? Or anything else around plugins?
>
> I'm definitely interested to hear more. I'd love to help out with
> getting a common place for contributed couchdb things to be indexed
> and published. Plugins seem like an ideal testing ground. How
> do you
> imagine a plugin registry working?
I think npm would be the way to go in the future, maybe we need a bit of iteration before we’re ready to go directly to using the public npm perhaps.
We will have a “trusted couchdb instance” available soon (before Christmas, this year) in the ASF infrastructure which could trivially be set up to host these. I’ll ping dev@ as soon as its up, and there’s no reason why it couldn’t host a couch configured like npm to start with. Or other stuff.
A+
Dave
Re: Plugin Registry (Was Summary of IRC meeting in #couchdb-meeting)
Posted by Alexander Shorin <kx...@gmail.com>.
On Thu, Nov 14, 2013 at 10:52 PM, till <kl...@gmail.com> wrote:
> - enforce semantic versions
> - don’t allow people to re-upload releases
> - make it easy to mirror it
> - some kind of signature for plugins/verification
All of this could be done with CouchDB, validatation functions and
replication. Why not?
--
,,,^..^,,,
Re: Plugin Registry (Was Summary of IRC meeting in
#couchdb-meeting)
Posted by till <kl...@gmail.com>.
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
Re: Plugin Registry (Was Summary of IRC meeting in #couchdb-meeting)
Posted by Brian Mitchell <br...@strmpnk.co>.
On Thu, Nov 14, 2013 at 1:52 PM, till <kl...@gmail.com> wrote:
>
>
> On Thursday 14 November 2013 at 18:28, Simon Metson wrote:
>
>> Hey,
>>
>> > > I agree, src/couch_plugins/README.md (http://README.md) has a quasi roadmap that I want to work
>> > > towards. The only edit for now would be that I’d like a registry that can be
>> > > update independently from CouchDB releases. Would you be interested in helping
>> > > out with that? Or anything else around plugins?
>> > >
>> >
>> >
>> > I'm definitely interested to hear more. I'd love to help out with
>> > getting a common place for contributed couchdb things to be indexed
>> > and published. Plugins seem like an ideal testing ground. How do you
>> > imagine a plugin registry working?
>> >
>>
>>
>> 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?
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:
>
> - enforce semantic versions
+1. We should expect plugins to follow the same conventions that CouchDB does.
> - don’t allow people to re-upload releases
Yes. We could avoid this partly by making releases more like immutable
documents.
> - 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).
> - some kind of signature for plugins/verification
+1.
Re: Plugin Registry (Was Summary of IRC meeting in
#couchdb-meeting)
Posted by till <kl...@gmail.com>.
On Thursday 14 November 2013 at 18:28, Simon Metson wrote:
> Hey,
>
> > > I agree, src/couch_plugins/README.md (http://README.md) has a quasi roadmap that I want to work
> > > towards. The only edit for now would be that I’d like a registry that can be
> > > update independently from CouchDB releases. Would you be interested in helping
> > > out with that? Or anything else around plugins?
> > >
> >
> >
> > I'm definitely interested to hear more. I'd love to help out with
> > getting a common place for contributed couchdb things to be indexed
> > and published. Plugins seem like an ideal testing ground. How do you
> > imagine a plugin registry working?
> >
>
>
> 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.
Then minor nitpicks like:
- enforce semantic versions
- don’t allow people to re-upload releases
- make it easy to mirror it
- some kind of signature for plugins/verification
Till
Re: Plugin Registry (Was Summary of IRC meeting in
#couchdb-meeting)
Posted by Simon Metson <si...@cloudant.com>.
Hey,
> > I agree, src/couch_plugins/README.md (http://README.md) has a quasi roadmap that I want to work
> > towards. The only edit for now would be that I’d like a registry that can be
> > update independently from CouchDB releases. Would you be interested in helping
> > out with that? Or anything else around plugins?
>
> I'm definitely interested to hear more. I'd love to help out with
> getting a common place for contributed couchdb things to be indexed
> and published. Plugins seem like an ideal testing ground. How do you
> imagine a plugin registry working?
I’m interested in this too. Can we pick up stuff from npm?
Cheers
Simon