Re: CouchDB OTP
On Thu, Nov 4, 2010 at 12:49 AM, Noah Slater wrote: > > On 4 Nov 2010, at 04:41, Paul Davis wrote: > >> The issue with configure.ac is that it is a pre-distribution method >> for configuring a build system. As in, if we claim some functionality >> for Erlang builds via configure.ac, then we're tacitly making the >> claim that we'll have multiple distributions, a "rebar distribution" >> and a "erlc distribution". Its not unfathomable to me that we just say >> "tarballs will use erlc" which is not out of the question, but it >> still seems weird. > > Nu, uh... > > `./configure` is run during every local install. > > What I described is possible for every single individual user. > Oh right. For some reason I was thinking you were saying to put the "erlc vs rebar" decision in configure.ac instead of "generate the logic to decide when ./configure is run." Hence why you are sempi. >> The other issue is that I do realize that we can leverage ./configure >> to (for lack of alternate verb) configure the build. The issue with >> rebar and VPATH builds is that reading the docs and source code, I >> could not see any method to tell rebar "your source files are in this >> place, place your output in this other place." As I read rebar's >> source, its output paths are absolutely defined by the input file >> name. I'm guessing that Noah is incredulous by this claim, but I will >> remind him that rebar is awesome precisely because of this sort of >> prejudice, its just not VPATH aware. > > So, it's output files are in predictable locations? > > Sounds like a good opportunity for post-hoc installation logic. :) > > Either way, I see it like this: > > - Before build time we can control what rebar sees. > > - After build time, we can modify and move files as we want. > > What more could you possibly ask for? > > Except for the problem to go away entirely, of course. :) > Quite predictable locations. But the way we would predict what goes where would basically be to copy portions of the source tree to the build tree before invoking rebar. Its not out of the question, but seems "not quite right". >> Also, writable source trees. I know Noah knows this, but people that >> aren't familiar with VPATH often get tripped up on this. The key thing >> that made this click for me was to imagine expanding a tarball, >> writing the source code to a CD, and then building and installing from >> that CD without copying source files. > > Good catch, I forget to mention a lot of this stuff. :) > >> I think that's the right sentiment, but slightly not quite right I >> think. The analogy I would use would be more like, "Reconciling Erlang >> builds with Autotools builds is like trying to translate poetry from >> Turkish to Navajo." > > Actually, I think it should be perfectly surmountable. The key will be in > separating the Erlang build from the main build. Think of it like compiling a > C app. You wouldn't have the compiler try to move the files into location, or > handle the installation of the /etc/config/file. So, just treat rebar, or > whatever, as the compilation step for an OTP app (even though the result is a > directory tree, a bit like NeXT really) and use Autotools to plop that into > the right location on the filesystem. Exactly. I think its quite possible, I just don't speak Autofu as fluently as you to know what the "elegant" solution would be here. My concern is if our 'surmounting effort' turns into a "'oh fuck, that doesn't work on Solaris 3.3 when running on a Sparc Ultra2400 with the 32GiB RAM expansion while PXE booting off a Broadcom 802.11k chipset.' effort". I'm just saying... HTH, Paul Davis
Re: CouchDB OTP
On 4 Nov 2010, at 04:41, Paul Davis wrote: > The issue with configure.ac is that it is a pre-distribution method > for configuring a build system. As in, if we claim some functionality > for Erlang builds via configure.ac, then we're tacitly making the > claim that we'll have multiple distributions, a "rebar distribution" > and a "erlc distribution". Its not unfathomable to me that we just say > "tarballs will use erlc" which is not out of the question, but it > still seems weird. Nu, uh... `./configure` is run during every local install. What I described is possible for every single individual user. > The other issue is that I do realize that we can leverage ./configure > to (for lack of alternate verb) configure the build. The issue with > rebar and VPATH builds is that reading the docs and source code, I > could not see any method to tell rebar "your source files are in this > place, place your output in this other place." As I read rebar's > source, its output paths are absolutely defined by the input file > name. I'm guessing that Noah is incredulous by this claim, but I will > remind him that rebar is awesome precisely because of this sort of > prejudice, its just not VPATH aware. So, it's output files are in predictable locations? Sounds like a good opportunity for post-hoc installation logic. :) Either way, I see it like this: - Before build time we can control what rebar sees. - After build time, we can modify and move files as we want. What more could you possibly ask for? Except for the problem to go away entirely, of course. :) > Also, writable source trees. I know Noah knows this, but people that > aren't familiar with VPATH often get tripped up on this. The key thing > that made this click for me was to imagine expanding a tarball, > writing the source code to a CD, and then building and installing from > that CD without copying source files. Good catch, I forget to mention a lot of this stuff. :) > I think that's the right sentiment, but slightly not quite right I > think. The analogy I would use would be more like, "Reconciling Erlang > builds with Autotools builds is like trying to translate poetry from > Turkish to Navajo." Actually, I think it should be perfectly surmountable. The key will be in separating the Erlang build from the main build. Think of it like compiling a C app. You wouldn't have the compiler try to move the files into location, or handle the installation of the /etc/config/file. So, just treat rebar, or whatever, as the compilation step for an OTP app (even though the result is a directory tree, a bit like NeXT really) and use Autotools to plop that into the right location on the filesystem.
Re: CouchDB OTP
On Wed, Nov 3, 2010 at 11:53 PM, Noah Slater wrote: > > On 4 Nov 2010, at 03:27, Paul Davis wrote: > >> 1. We have constraints. Noah's pointed out a few, but I don't even >> think that list is exhaustive. A project like CouchDB needs to pay >> attention to a lot of different details. I've said before that Noah is >> the Chuck Norris of Autotools, so any proposed changes will need to be >> cleared by him. He is the de facto BDFL for our build system and I >> will vote with him lock step on any proposal. >> >> 2. There are lots of things in our current build system that may seem >> innocuous at first, but turn out to be A Big Deal in some specific >> circumstances that aren't always apparent at first glance. >> >> 3. A lot of changes I see in your CouchDB branch aren't going to fly. >> Some reasons may seem trivial but this is me relying on knowledge from >> Noah Chuck Norris Slater. > > I love this mailing list. *g* > >> 4. I'm not sure about Sinan, but rebar won't work out of the box for a >> default build tool because of a lack of support for VPATH builds. At >> this moment I'm still concentrating on making sure we can do a full >> rebar build to support things like Erlang releases, but it's been >> de-prioritized to a "secondary build system" status. If Sinan can do >> VPATH builds, then I think it'd be a very good thing to support. >> >> 5. Erlang build knowledge is at some level, incompatible with >> Autotools build knowledge. We need to find a common ground and figure >> out where we can compromise to hopefully make both work. My current >> shimmering of an idea for rebar was to have a make target that was >> something like "make rebar" which would short circuit some parts of a >> default build with rebar. Its possible that we can revamp part of the >> build system to overcome the constraints of Autotools, but as I see it >> the first move might just make a "developer friendly" alternate build >> style. > > I'm not sure if I've mentioned this before, but I see a way forward with > this. I'm going to assume that you (Paul, specifically here) know enough > about Autotools to be familiar with the role that configure.ac plays in the > whole process. > > To break it down for you: > > - `./configure` preps the source tree for build-specific rules > > - `make` preps the files needed to install > > - `make` install installs the files > > A key to realising the power of this is in considering what you can do with > the configure.ac script, which in turns is "compiled" down to the configure > script the user runs. For example, you can ALTER the build process during > `make` by having configure.ac modify or write out customised files. > > So, as far as I see it, making rebar VPATH compatible should be as simple as > creating the rebar spec file (to make up some terminology - whatever it is > that tells rebar how to build stuff) during the `./configure` step. > Presumably, by writing files, or even replacing text within files. > > You've seen the @variables@ in some locations, Paul? They're things that we > replace during the `./configure` step. Nothing stopping you from using a > @PREFIX@ type variable for the file that is ultimately used during the `make` > step. > I preface with this with the fact that I do not wish to know the wrath of a Chuck Norris round house kick the face. The issue with configure.ac is that it is a pre-distribution method for configuring a build system. As in, if we claim some functionality for Erlang builds via configure.ac, then we're tacitly making the claim that we'll have multiple distributions, a "rebar distribution" and a "erlc distribution". Its not unfathomable to me that we just say "tarballs will use erlc" which is not out of the question, but it still seems weird. The other issue is that I do realize that we can leverage ./configure to (for lack of alternate verb) configure the build. The issue with rebar and VPATH builds is that reading the docs and source code, I could not see any method to tell rebar "your source files are in this place, place your output in this other place." As I read rebar's source, its output paths are absolutely defined by the input file name. I'm guessing that Noah is incredulous by this claim, but I will remind him that rebar is awesome precisely because of this sort of prejudice, its just not VPATH aware. >> 7. Removing dependencies from the source tree is not going to happen >> any time soon. I wish we didn't have to vendor so many projects, but >> we have to remember that a majority of people building CouchDB are not >> Erlangians. Forcing our community to install a number of Erlang >> dependencies to build CouchDB would be a very large hurdle to >> navigate. I know that there are projects like faxien and rebar's git >> support to overcome this, but I don't feel that there is a solution >> that sufficiently addresses this issue. > > And doing it at build time breaks a really fundamental rule of build systems.
[jira] Commented: (COUCHDB-933) Remove Dependancy on Inets
[ https://issues.apache.org/jira/browse/COUCHDB-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12928116#action_12928116 ] Dale Harvey commented on COUCHDB-933: - Yeh you are right, I amended the patch so it only stops couch manually starting inets on boot, plus switched all the tests from inets to ibrowse, which lets us include inets as a library but not require it to be started to run couch or the tests. > Remove Dependancy on Inets > -- > > Key: COUCHDB-933 > URL: https://issues.apache.org/jira/browse/COUCHDB-933 > Project: CouchDB > Issue Type: Improvement > Components: Infrastructure >Reporter: Dale Harvey >Priority: Minor > Attachments: anon.patch > > > Inets is not used internally, but is started by the application and is also > used in the etap tests, switch out all uses of inets to ibrowse -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CouchDB OTP
On 4 Nov 2010, at 03:27, Paul Davis wrote: > 1. We have constraints. Noah's pointed out a few, but I don't even > think that list is exhaustive. A project like CouchDB needs to pay > attention to a lot of different details. I've said before that Noah is > the Chuck Norris of Autotools, so any proposed changes will need to be > cleared by him. He is the de facto BDFL for our build system and I > will vote with him lock step on any proposal. > > 2. There are lots of things in our current build system that may seem > innocuous at first, but turn out to be A Big Deal in some specific > circumstances that aren't always apparent at first glance. > > 3. A lot of changes I see in your CouchDB branch aren't going to fly. > Some reasons may seem trivial but this is me relying on knowledge from > Noah Chuck Norris Slater. I love this mailing list. *g* > 4. I'm not sure about Sinan, but rebar won't work out of the box for a > default build tool because of a lack of support for VPATH builds. At > this moment I'm still concentrating on making sure we can do a full > rebar build to support things like Erlang releases, but it's been > de-prioritized to a "secondary build system" status. If Sinan can do > VPATH builds, then I think it'd be a very good thing to support. > > 5. Erlang build knowledge is at some level, incompatible with > Autotools build knowledge. We need to find a common ground and figure > out where we can compromise to hopefully make both work. My current > shimmering of an idea for rebar was to have a make target that was > something like "make rebar" which would short circuit some parts of a > default build with rebar. Its possible that we can revamp part of the > build system to overcome the constraints of Autotools, but as I see it > the first move might just make a "developer friendly" alternate build > style. I'm not sure if I've mentioned this before, but I see a way forward with this. I'm going to assume that you (Paul, specifically here) know enough about Autotools to be familiar with the role that configure.ac plays in the whole process. To break it down for you: - `./configure` preps the source tree for build-specific rules - `make` preps the files needed to install - `make` install installs the files A key to realising the power of this is in considering what you can do with the configure.ac script, which in turns is "compiled" down to the configure script the user runs. For example, you can ALTER the build process during `make` by having configure.ac modify or write out customised files. So, as far as I see it, making rebar VPATH compatible should be as simple as creating the rebar spec file (to make up some terminology - whatever it is that tells rebar how to build stuff) during the `./configure` step. Presumably, by writing files, or even replacing text within files. You've seen the @variables@ in some locations, Paul? They're things that we replace during the `./configure` step. Nothing stopping you from using a @PREFIX@ type variable for the file that is ultimately used during the `make` step. > 7. Removing dependencies from the source tree is not going to happen > any time soon. I wish we didn't have to vendor so many projects, but > we have to remember that a majority of people building CouchDB are not > Erlangians. Forcing our community to install a number of Erlang > dependencies to build CouchDB would be a very large hurdle to > navigate. I know that there are projects like faxien and rebar's git > support to overcome this, but I don't feel that there is a solution > that sufficiently addresses this issue. And doing it at build time breaks a really fundamental rule of build systems. Never assume a network connection > 8. I don't know about Sinan or Rebar's platform support specifically. > Building C code portably is very very hard. I know that people detest > Autotools for such things, but its got an uncountable number of man > years addressing platform specific build issues. I don't think its > impossible to replace for building C code, I just see it as staring at > a mountain when people suggest it. IIRC, one of my first conversations > with Noah was switching to SCons. As much as it pains me now to admit, > I'm glad at he laughed at me then. I'm going to quote Mark Pilgrim on this: 'Here’s the basic problem: you’re writing a text editor. Stop doing that. It’s 2007. Saying to yourself “I’m gonna build my own text editor” is as silly as saying “I’m gonna build my own build system” or “I’m gonna build my own amusement park.” Blackjack and hookers and all that. Writing a great text editor is insanely difficult. There is a certain class of software that sounds easy but is actually insanely difficult. I call it “garden path software.” If I ever start a software company, I’ll name it “Garden Path Software,” but until then, just stop.' Autotools is a big, stinking, POS — but it gets the job done, precisely because it's been
[jira] Updated: (COUCHDB-933) Remove Dependancy on Inets
[ https://issues.apache.org/jira/browse/COUCHDB-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Harvey updated COUCHDB-933: Attachment: (was: inets.patch) > Remove Dependancy on Inets > -- > > Key: COUCHDB-933 > URL: https://issues.apache.org/jira/browse/COUCHDB-933 > Project: CouchDB > Issue Type: Improvement > Components: Infrastructure >Reporter: Dale Harvey >Priority: Minor > Attachments: anon.patch > > > Inets is not used internally, but is started by the application and is also > used in the etap tests, switch out all uses of inets to ibrowse -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-933) Remove Dependancy on Inets
[ https://issues.apache.org/jira/browse/COUCHDB-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Harvey updated COUCHDB-933: Attachment: anon.patch > Remove Dependancy on Inets > -- > > Key: COUCHDB-933 > URL: https://issues.apache.org/jira/browse/COUCHDB-933 > Project: CouchDB > Issue Type: Improvement > Components: Infrastructure >Reporter: Dale Harvey >Priority: Minor > Attachments: anon.patch > > > Inets is not used internally, but is started by the application and is also > used in the etap tests, switch out all uses of inets to ibrowse -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-933) Remove Dependancy on Inets
[ https://issues.apache.org/jira/browse/COUCHDB-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Harvey updated COUCHDB-933: Attachment: (was: inets.patch) > Remove Dependancy on Inets > -- > > Key: COUCHDB-933 > URL: https://issues.apache.org/jira/browse/COUCHDB-933 > Project: CouchDB > Issue Type: Improvement > Components: Infrastructure >Reporter: Dale Harvey >Priority: Minor > Attachments: anon.patch > > > Inets is not used internally, but is started by the application and is also > used in the etap tests, switch out all uses of inets to ibrowse -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-933) Remove Dependancy on Inets
[ https://issues.apache.org/jira/browse/COUCHDB-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Harvey updated COUCHDB-933: Attachment: inets.patch > Remove Dependancy on Inets > -- > > Key: COUCHDB-933 > URL: https://issues.apache.org/jira/browse/COUCHDB-933 > Project: CouchDB > Issue Type: Improvement > Components: Infrastructure >Reporter: Dale Harvey >Priority: Minor > Attachments: inets.patch, inets.patch > > > Inets is not used internally, but is started by the application and is also > used in the etap tests, switch out all uses of inets to ibrowse -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CouchDB OTP
On Wed, Nov 3, 2010 at 8:45 PM, Tristan Sloughter wrote: > Agreed. That sounds like a good plan. I'd just want to ensure that the > Erlang side can be installed as a release and run as a release, or included > as apps, to a project and run without a problem. This can be complicated by > having the build system do so much with the configuration files. Which is > why I simply put them in priv and reference them that way. But something can > be figured out. > > Tristan > > On Wed, Nov 3, 2010 at 7:40 PM, Noah Slater wrote: > >> >> On 4 Nov 2010, at 00:33, Tristan Sloughter wrote: >> >> > What complex stuff is the build system dealing with? >> >> Everything outside of "erlc" :) >> >> - VPATH builds >> - Configuring the install to find the location of C libraries >> - Customising the install for users >> - Setting up the system infrastructure for CouchDB to function >> - Making sure things work across platforms >> - Building customised versions of binaries and scripts >> >> > I'm separating the >> > config file (and similar files) problem and the icu and couch_js problem. >> I >> > was hoping building those few C files wouldn't be bad, but I guess that >> is >> > not true from what you are saying? >> >> Doing the build system for an operating system daemon is Hard. >> >> > I'd still say it should be autotools, or whatever, inside an Erlang build >> > system. >> >> Basically, I would like to see the new build system separate the package >> into two components. The CouchDB OTP application, which is build using some >> Erlang appropriate build system (like rebar, or whatever) and everything >> else. Everything else is handled by Autotools, like it is now. Autotools is >> also responsible for delegating the Erlang work off to the other build >> system. >> >> A good way forward would be: >> >> - Decide the minimum set of files needed for the Erlang build. >> >> - Sandbox them into a directory along with the build files. >> >> - Create a Makefile.am file in that directory. >> >> - Hook the new system into the Autotools system. >> >> That should work. >> >> We get to keep teh AWSUM POWAH of Autotools, and have an OTP app. :) >> >> Valediction, >> >> N >> >> > Tristan, Apologies for not replying earlier. I meant to but got distracted by something shiny. As Noah points out there are quite a few issues that are going to be pain points with transitioning towards a non Autotools build. I'm confident that we can and will but there are a few things to consider as we do this. The following is going to be a brain dump to try and outline the issues as best as I can. These are in no specific order but hopefully give a good outline of what we're facing. I will also preference this with the fact that our current source tree is in desperate need of a makeover. We've been talking about it for awhile and its at the point that it just needs to happen. The rest that follows is my gathering of thoughts for the move. 1. We have constraints. Noah's pointed out a few, but I don't even think that list is exhaustive. A project like CouchDB needs to pay attention to a lot of different details. I've said before that Noah is the Chuck Norris of Autotools, so any proposed changes will need to be cleared by him. He is the de facto BDFL for our build system and I will vote with him lock step on any proposal. 2. There are lots of things in our current build system that may seem innocuous at first, but turn out to be A Big Deal in some specific circumstances that aren't always apparent at first glance. 3. A lot of changes I see in your CouchDB branch aren't going to fly. Some reasons may seem trivial but this is me relying on knowledge from Noah Chuck Norris Slater. 4. I'm not sure about Sinan, but rebar won't work out of the box for a default build tool because of a lack of support for VPATH builds. At this moment I'm still concentrating on making sure we can do a full rebar build to support things like Erlang releases, but it's been de-prioritized to a "secondary build system" status. If Sinan can do VPATH builds, then I think it'd be a very good thing to support. 5. Erlang build knowledge is at some level, incompatible with Autotools build knowledge. We need to find a common ground and figure out where we can compromise to hopefully make both work. My current shimmering of an idea for rebar was to have a make target that was something like "make rebar" which would short circuit some parts of a default build with rebar. Its possible that we can revamp part of the build system to overcome the constraints of Autotools, but as I see it the first move might just make a "developer friendly" alternate build style. 6. Your CouchDB branch has some major source movement. Unfortunately the ASF has not yet moved to having native git support. As such, any such patches of this magnitude must be developed with Subversion in mind. The reason is that we cannot develop this patch set in git and apply it directly to svn
[jira] Commented: (COUCHDB-933) Remove Dependancy on Inets
[ https://issues.apache.org/jira/browse/COUCHDB-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12928083#action_12928083 ] Adam Kocoloski commented on COUCHDB-933: Seems good at first glance. For what it's worth, couch_log uses the httpd_util module from inets to format timestamps, so it can't be removed entirely from a standalone release built with reltool. > Remove Dependancy on Inets > -- > > Key: COUCHDB-933 > URL: https://issues.apache.org/jira/browse/COUCHDB-933 > Project: CouchDB > Issue Type: Improvement > Components: Infrastructure >Reporter: Dale Harvey >Priority: Minor > Attachments: inets.patch > > > Inets is not used internally, but is started by the application and is also > used in the etap tests, switch out all uses of inets to ibrowse -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-933) Remove Dependancy on Inets
[ https://issues.apache.org/jira/browse/COUCHDB-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Harvey updated COUCHDB-933: Attachment: inets.patch > Remove Dependancy on Inets > -- > > Key: COUCHDB-933 > URL: https://issues.apache.org/jira/browse/COUCHDB-933 > Project: CouchDB > Issue Type: Improvement > Components: Infrastructure >Reporter: Dale Harvey >Priority: Minor > Attachments: inets.patch > > > Inets is not used internally, but is started by the application and is also > used in the etap tests, switch out all uses of inets to ibrowse -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-933) Remove Dependancy on Inets
Remove Dependancy on Inets -- Key: COUCHDB-933 URL: https://issues.apache.org/jira/browse/COUCHDB-933 Project: CouchDB Issue Type: Improvement Components: Infrastructure Reporter: Dale Harvey Priority: Minor Inets is not used internally, but is started by the application and is also used in the etap tests, switch out all uses of inets to ibrowse -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CouchDB OTP
Agreed. That sounds like a good plan. I'd just want to ensure that the Erlang side can be installed as a release and run as a release, or included as apps, to a project and run without a problem. This can be complicated by having the build system do so much with the configuration files. Which is why I simply put them in priv and reference them that way. But something can be figured out. Tristan On Wed, Nov 3, 2010 at 7:40 PM, Noah Slater wrote: > > On 4 Nov 2010, at 00:33, Tristan Sloughter wrote: > > > What complex stuff is the build system dealing with? > > Everything outside of "erlc" :) > > - VPATH builds > - Configuring the install to find the location of C libraries > - Customising the install for users > - Setting up the system infrastructure for CouchDB to function > - Making sure things work across platforms > - Building customised versions of binaries and scripts > > > I'm separating the > > config file (and similar files) problem and the icu and couch_js problem. > I > > was hoping building those few C files wouldn't be bad, but I guess that > is > > not true from what you are saying? > > Doing the build system for an operating system daemon is Hard. > > > I'd still say it should be autotools, or whatever, inside an Erlang build > > system. > > Basically, I would like to see the new build system separate the package > into two components. The CouchDB OTP application, which is build using some > Erlang appropriate build system (like rebar, or whatever) and everything > else. Everything else is handled by Autotools, like it is now. Autotools is > also responsible for delegating the Erlang work off to the other build > system. > > A good way forward would be: > >- Decide the minimum set of files needed for the Erlang build. > >- Sandbox them into a directory along with the build files. > >- Create a Makefile.am file in that directory. > >- Hook the new system into the Autotools system. > > That should work. > > We get to keep teh AWSUM POWAH of Autotools, and have an OTP app. :) > > Valediction, > > N > >
Re: CouchDB OTP
P.S. Glad you enjoyed ErlangCamp :). Sucks you didn't make the night events, they were great. Maybe next time! On Wed, Nov 3, 2010 at 7:39 PM, Tristan Sloughter < tristan.slough...@gmail.com> wrote: > I see it was already discussed about breaking CouchDB into apps: > > couch_core: The core Erlang modules for storing docs and managing > "internal infrastructure" > couch_view: The view engine as well as the holder for managing OS > processes. > couch_rep: couch_rep*.erl > couch_externals: couch_external*.erl > couch_httpd: couch_http*.erl > > I was going to also start on that after getting the build stable. Now I see > the work of deciding what goes where was already done :). > > This is great. I hope my work on this can be helpful for the move in 1.1.x > you guys want to make. > > Tristan > > On Wed, Nov 3, 2010 at 7:33 PM, Tristan Sloughter < > tristan.slough...@gmail.com> wrote: > >> Hmm, ok. I have replaced the build system. I am using sinan but it should >> be buildable now with any Erlang/OTP build tool, like rebar. I am just >> running it as a release from a script that erl-execs the boot file. >> >> What complex stuff is the build system dealing with? I'm separating the >> config file (and similar files) problem and the icu and couch_js problem. I >> was hoping building those few C files wouldn't be bad, but I guess that is >> not true from what you are saying? >> >> I'd still say it should be autotools, or whatever, inside an Erlang build >> system. >> >> Tristan >> >> >> On Wed, Nov 3, 2010 at 7:28 PM, Noah Slater wrote: >> >>> Have you wholesale replaced the existing build system? >>> >>> If you have, it's going to be a tad more complex than knocking up a few >>> makefiles to compile C. There's lots of very complex stuff our build system >>> copes with at the moment. I'm not convinced it can be replaced by an Erlang >>> build system and a few shell scripts. We've had chats about improving the >>> build system before, and I think the consensus is that we wrap an Erlang >>> build system WITHIN the Autotools system. >>> >>> What are you thoughts? >>> >>> On 4 Nov 2010, at 00:04, Tristan Sloughter wrote: >>> >>> > If anyone by chance has or can easily create some simplistic make files >>> or >>> > something for compiling the C code that would be AWESOME. I haven't had >>> time >>> > to dig around what is needed to compile the different pieces but its >>> the >>> > last major piece to complete. >>> > >>> > Tristan >>> > >>> > On Wed, Nov 3, 2010 at 10:52 AM, Tristan Sloughter < >>> > tristan.slough...@gmail.com> wrote: >>> > >>> >> Hi everyone, I have a github fork from apache/couchdb >>> >> https://github.com/tsloughter/couchdb that I modified to be more OTP >>> >> compliant and now builds with sinan (from http://erlware.org). There >>> >> wasn't much that I've done so far. I moved the CouchDB app under >>> >> lib/couchdb. I removed the other apps from the source tree, they can >>> easily >>> >> be installed with faxien (from http://erlware.org) and versions can >>> be >>> >> declared if necessary. I changed the _app.erl file to not start >>> applications >>> >> and added those applications instead to the applications list in the >>> .app >>> >> file. They will be started properly by the release's boot script. >>> >> >>> >> I moved all non-Erlang stuff to lib/couchdb/priv. >>> >> >>> >> I still have a number of things to do that I hope to get to tonight. >>> First, >>> >> fix up the two scripts under bin/. Fix the configuration file >>> locations >>> >> (some stuff is hardcoded for my environment). Add a hook to sinan to >>> compile >>> >> the icu driver -- right now I just copied the library over from a >>> build of >>> >> CouchDB I did separately. >>> >> >>> >> There are probably a few other things.. But I was able to do an >>> >> application:start(couchdb) last night and see it working :). >>> >> >>> >> There were a few things I thought of changing within the code as I dug >>> >> around but those are a separate issue that I'll bring up in discussion >>> after >>> >> all this is complete. >>> >> >>> >> Tristan >>> >> >>> >>> >> >
Re: CouchDB OTP
On 4 Nov 2010, at 00:33, Tristan Sloughter wrote: > What complex stuff is the build system dealing with? Everything outside of "erlc" :) - VPATH builds - Configuring the install to find the location of C libraries - Customising the install for users - Setting up the system infrastructure for CouchDB to function - Making sure things work across platforms - Building customised versions of binaries and scripts > I'm separating the > config file (and similar files) problem and the icu and couch_js problem. I > was hoping building those few C files wouldn't be bad, but I guess that is > not true from what you are saying? Doing the build system for an operating system daemon is Hard. > I'd still say it should be autotools, or whatever, inside an Erlang build > system. Basically, I would like to see the new build system separate the package into two components. The CouchDB OTP application, which is build using some Erlang appropriate build system (like rebar, or whatever) and everything else. Everything else is handled by Autotools, like it is now. Autotools is also responsible for delegating the Erlang work off to the other build system. A good way forward would be: - Decide the minimum set of files needed for the Erlang build. - Sandbox them into a directory along with the build files. - Create a Makefile.am file in that directory. - Hook the new system into the Autotools system. That should work. We get to keep teh AWSUM POWAH of Autotools, and have an OTP app. :) Valediction, N
Re: CouchDB OTP
I see it was already discussed about breaking CouchDB into apps: couch_core: The core Erlang modules for storing docs and managing "internal infrastructure" couch_view: The view engine as well as the holder for managing OS processes. couch_rep: couch_rep*.erl couch_externals: couch_external*.erl couch_httpd: couch_http*.erl I was going to also start on that after getting the build stable. Now I see the work of deciding what goes where was already done :). This is great. I hope my work on this can be helpful for the move in 1.1.x you guys want to make. Tristan On Wed, Nov 3, 2010 at 7:33 PM, Tristan Sloughter < tristan.slough...@gmail.com> wrote: > Hmm, ok. I have replaced the build system. I am using sinan but it should > be buildable now with any Erlang/OTP build tool, like rebar. I am just > running it as a release from a script that erl-execs the boot file. > > What complex stuff is the build system dealing with? I'm separating the > config file (and similar files) problem and the icu and couch_js problem. I > was hoping building those few C files wouldn't be bad, but I guess that is > not true from what you are saying? > > I'd still say it should be autotools, or whatever, inside an Erlang build > system. > > Tristan > > > On Wed, Nov 3, 2010 at 7:28 PM, Noah Slater wrote: > >> Have you wholesale replaced the existing build system? >> >> If you have, it's going to be a tad more complex than knocking up a few >> makefiles to compile C. There's lots of very complex stuff our build system >> copes with at the moment. I'm not convinced it can be replaced by an Erlang >> build system and a few shell scripts. We've had chats about improving the >> build system before, and I think the consensus is that we wrap an Erlang >> build system WITHIN the Autotools system. >> >> What are you thoughts? >> >> On 4 Nov 2010, at 00:04, Tristan Sloughter wrote: >> >> > If anyone by chance has or can easily create some simplistic make files >> or >> > something for compiling the C code that would be AWESOME. I haven't had >> time >> > to dig around what is needed to compile the different pieces but its the >> > last major piece to complete. >> > >> > Tristan >> > >> > On Wed, Nov 3, 2010 at 10:52 AM, Tristan Sloughter < >> > tristan.slough...@gmail.com> wrote: >> > >> >> Hi everyone, I have a github fork from apache/couchdb >> >> https://github.com/tsloughter/couchdb that I modified to be more OTP >> >> compliant and now builds with sinan (from http://erlware.org). There >> >> wasn't much that I've done so far. I moved the CouchDB app under >> >> lib/couchdb. I removed the other apps from the source tree, they can >> easily >> >> be installed with faxien (from http://erlware.org) and versions can be >> >> declared if necessary. I changed the _app.erl file to not start >> applications >> >> and added those applications instead to the applications list in the >> .app >> >> file. They will be started properly by the release's boot script. >> >> >> >> I moved all non-Erlang stuff to lib/couchdb/priv. >> >> >> >> I still have a number of things to do that I hope to get to tonight. >> First, >> >> fix up the two scripts under bin/. Fix the configuration file locations >> >> (some stuff is hardcoded for my environment). Add a hook to sinan to >> compile >> >> the icu driver -- right now I just copied the library over from a build >> of >> >> CouchDB I did separately. >> >> >> >> There are probably a few other things.. But I was able to do an >> >> application:start(couchdb) last night and see it working :). >> >> >> >> There were a few things I thought of changing within the code as I dug >> >> around but those are a separate issue that I'll bring up in discussion >> after >> >> all this is complete. >> >> >> >> Tristan >> >> >> >> >
Re: CouchDB OTP
Hmm, ok. I have replaced the build system. I am using sinan but it should be buildable now with any Erlang/OTP build tool, like rebar. I am just running it as a release from a script that erl-execs the boot file. What complex stuff is the build system dealing with? I'm separating the config file (and similar files) problem and the icu and couch_js problem. I was hoping building those few C files wouldn't be bad, but I guess that is not true from what you are saying? I'd still say it should be autotools, or whatever, inside an Erlang build system. Tristan On Wed, Nov 3, 2010 at 7:28 PM, Noah Slater wrote: > Have you wholesale replaced the existing build system? > > If you have, it's going to be a tad more complex than knocking up a few > makefiles to compile C. There's lots of very complex stuff our build system > copes with at the moment. I'm not convinced it can be replaced by an Erlang > build system and a few shell scripts. We've had chats about improving the > build system before, and I think the consensus is that we wrap an Erlang > build system WITHIN the Autotools system. > > What are you thoughts? > > On 4 Nov 2010, at 00:04, Tristan Sloughter wrote: > > > If anyone by chance has or can easily create some simplistic make files > or > > something for compiling the C code that would be AWESOME. I haven't had > time > > to dig around what is needed to compile the different pieces but its the > > last major piece to complete. > > > > Tristan > > > > On Wed, Nov 3, 2010 at 10:52 AM, Tristan Sloughter < > > tristan.slough...@gmail.com> wrote: > > > >> Hi everyone, I have a github fork from apache/couchdb > >> https://github.com/tsloughter/couchdb that I modified to be more OTP > >> compliant and now builds with sinan (from http://erlware.org). There > >> wasn't much that I've done so far. I moved the CouchDB app under > >> lib/couchdb. I removed the other apps from the source tree, they can > easily > >> be installed with faxien (from http://erlware.org) and versions can be > >> declared if necessary. I changed the _app.erl file to not start > applications > >> and added those applications instead to the applications list in the > .app > >> file. They will be started properly by the release's boot script. > >> > >> I moved all non-Erlang stuff to lib/couchdb/priv. > >> > >> I still have a number of things to do that I hope to get to tonight. > First, > >> fix up the two scripts under bin/. Fix the configuration file locations > >> (some stuff is hardcoded for my environment). Add a hook to sinan to > compile > >> the icu driver -- right now I just copied the library over from a build > of > >> CouchDB I did separately. > >> > >> There are probably a few other things.. But I was able to do an > >> application:start(couchdb) last night and see it working :). > >> > >> There were a few things I thought of changing within the code as I dug > >> around but those are a separate issue that I'll bring up in discussion > after > >> all this is complete. > >> > >> Tristan > >> > >
Re: CouchDB OTP
Hi Tristan, Great work on OTP'izing! I think the core team (not to speak for them, just going on what I've seen on this list) is moving towards (or has at least discussed) rebar + OTPizing for 1.1.0(?). The recent thread about this kicks off here: http://mail-archives.apache.org/mod_mbox/couchdb-dev/201010.mbox/%3caanlkti=hfpkehr9kov0gfajgorwqg+tetmrnz9my=...@mail.gmail.com%3e Breakdown of most of the issues from Paul Davis here: http://mail-archives.apache.org/mod_mbox/couchdb-dev/201010.mbox/%3caanlktinjxrxteeg2zdghengqy+-jol+yxgpyrpsfn...@mail.gmail.com%3e Cheers! -Jeff PS Also, thanks for ErlangCamp -- I had a blast and learned quite a bit -- unfortunately, didn't get to stick around in the evenings to socialise On Wed, Nov 3, 2010 at 8:04 PM, Tristan Sloughter < tristan.slough...@gmail.com> wrote: > If anyone by chance has or can easily create some simplistic make files or > something for compiling the C code that would be AWESOME. I haven't had > time > to dig around what is needed to compile the different pieces but its the > last major piece to complete. > > Tristan > > On Wed, Nov 3, 2010 at 10:52 AM, Tristan Sloughter < > tristan.slough...@gmail.com> wrote: > > > Hi everyone, I have a github fork from apache/couchdb > > https://github.com/tsloughter/couchdb that I modified to be more OTP > > compliant and now builds with sinan (from http://erlware.org). There > > wasn't much that I've done so far. I moved the CouchDB app under > > lib/couchdb. I removed the other apps from the source tree, they can > easily > > be installed with faxien (from http://erlware.org) and versions can be > > declared if necessary. I changed the _app.erl file to not start > applications > > and added those applications instead to the applications list in the .app > > file. They will be started properly by the release's boot script. > > > > I moved all non-Erlang stuff to lib/couchdb/priv. > > > > I still have a number of things to do that I hope to get to tonight. > First, > > fix up the two scripts under bin/. Fix the configuration file locations > > (some stuff is hardcoded for my environment). Add a hook to sinan to > compile > > the icu driver -- right now I just copied the library over from a build > of > > CouchDB I did separately. > > > > There are probably a few other things.. But I was able to do an > > application:start(couchdb) last night and see it working :). > > > > There were a few things I thought of changing within the code as I dug > > around but those are a separate issue that I'll bring up in discussion > after > > all this is complete. > > > > Tristan > > >
Re: CouchDB OTP
Have you wholesale replaced the existing build system? If you have, it's going to be a tad more complex than knocking up a few makefiles to compile C. There's lots of very complex stuff our build system copes with at the moment. I'm not convinced it can be replaced by an Erlang build system and a few shell scripts. We've had chats about improving the build system before, and I think the consensus is that we wrap an Erlang build system WITHIN the Autotools system. What are you thoughts? On 4 Nov 2010, at 00:04, Tristan Sloughter wrote: > If anyone by chance has or can easily create some simplistic make files or > something for compiling the C code that would be AWESOME. I haven't had time > to dig around what is needed to compile the different pieces but its the > last major piece to complete. > > Tristan > > On Wed, Nov 3, 2010 at 10:52 AM, Tristan Sloughter < > tristan.slough...@gmail.com> wrote: > >> Hi everyone, I have a github fork from apache/couchdb >> https://github.com/tsloughter/couchdb that I modified to be more OTP >> compliant and now builds with sinan (from http://erlware.org). There >> wasn't much that I've done so far. I moved the CouchDB app under >> lib/couchdb. I removed the other apps from the source tree, they can easily >> be installed with faxien (from http://erlware.org) and versions can be >> declared if necessary. I changed the _app.erl file to not start applications >> and added those applications instead to the applications list in the .app >> file. They will be started properly by the release's boot script. >> >> I moved all non-Erlang stuff to lib/couchdb/priv. >> >> I still have a number of things to do that I hope to get to tonight. First, >> fix up the two scripts under bin/. Fix the configuration file locations >> (some stuff is hardcoded for my environment). Add a hook to sinan to compile >> the icu driver -- right now I just copied the library over from a build of >> CouchDB I did separately. >> >> There are probably a few other things.. But I was able to do an >> application:start(couchdb) last night and see it working :). >> >> There were a few things I thought of changing within the code as I dug >> around but those are a separate issue that I'll bring up in discussion after >> all this is complete. >> >> Tristan >>
Re: CouchDB OTP
If anyone by chance has or can easily create some simplistic make files or something for compiling the C code that would be AWESOME. I haven't had time to dig around what is needed to compile the different pieces but its the last major piece to complete. Tristan On Wed, Nov 3, 2010 at 10:52 AM, Tristan Sloughter < tristan.slough...@gmail.com> wrote: > Hi everyone, I have a github fork from apache/couchdb > https://github.com/tsloughter/couchdb that I modified to be more OTP > compliant and now builds with sinan (from http://erlware.org). There > wasn't much that I've done so far. I moved the CouchDB app under > lib/couchdb. I removed the other apps from the source tree, they can easily > be installed with faxien (from http://erlware.org) and versions can be > declared if necessary. I changed the _app.erl file to not start applications > and added those applications instead to the applications list in the .app > file. They will be started properly by the release's boot script. > > I moved all non-Erlang stuff to lib/couchdb/priv. > > I still have a number of things to do that I hope to get to tonight. First, > fix up the two scripts under bin/. Fix the configuration file locations > (some stuff is hardcoded for my environment). Add a hook to sinan to compile > the icu driver -- right now I just copied the library over from a build of > CouchDB I did separately. > > There are probably a few other things.. But I was able to do an > application:start(couchdb) last night and see it working :). > > There were a few things I thought of changing within the code as I dug > around but those are a separate issue that I'll bring up in discussion after > all this is complete. > > Tristan >
[jira] Commented: (COUCHDB-523) View API POST keys to retrieve multiple docs by key could also allow for multiple 'range' queries, i.e. an array of { startkey: .., endkey: ... } params in the POST
[
https://issues.apache.org/jira/browse/COUCHDB-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12927982#action_12927982
]
Paul Joseph Davis commented on COUCHDB-523:
---
I would say that Adam's array based approach is probably going to be more
sensible as it allows people to more easily control the order in which the
queries are processed in the case where someone wants to aggregate some sort of
result across the multiple views.
For the response I think having a {"results": $array_of_results} wrapper is
probably better as it allows for future changes more easily if we start
annotating that response.
Just for fun, has anyone considered how this would integrate with _lists? Or if
we people should be allowed to make queries on multiple views, and if so if
they should or shouldn't be scoped to a design doc?
> View API POST keys to retrieve multiple docs by key could also allow for
> multiple 'range' queries, i.e. an array of { startkey: .., endkey: ... }
> params in the POST
>
>
> Key: COUCHDB-523
> URL: https://issues.apache.org/jira/browse/COUCHDB-523
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
>Reporter: Nathan Stott
>Assignee: Adam Kocoloski
>Priority: Minor
> Fix For: 1.1
>
> Attachments: couch_httpd_view.erl, multi_start_end_key.diff,
> ranged_key_post.diff
>
>
> It would be useful if I could do a single POST to a view to retrieve multiple
> ranges specified by startkey, endkey.
> The format could be as follows:
> { "ranges": [ { "startkey": "a", "endkey": "c" }, { "startkey":"g",
> "endkey":"z" } ] }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-523) View API POST keys to retrieve multiple docs by key could also allow for multiple 'range' queries, i.e. an array of { startkey: .., endkey: ... } params in the POST
[
https://issues.apache.org/jira/browse/COUCHDB-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12927976#action_12927976
]
Adam Kocoloski commented on COUCHDB-523:
Hi Anand, I'd like to see some of the other commenters weigh in on that one.
Personally I think it'd be a bit of a hassle to name each of my queries in a
multi-query request. I think I prefer the order-preserving behavior of an
Array, where I could construct my queries Array in order and then just
concatenate the rows from the individual responses.
I can say that implementing the API as you've written it is not much more
difficult than the Array-based one.
> View API POST keys to retrieve multiple docs by key could also allow for
> multiple 'range' queries, i.e. an array of { startkey: .., endkey: ... }
> params in the POST
>
>
> Key: COUCHDB-523
> URL: https://issues.apache.org/jira/browse/COUCHDB-523
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
>Reporter: Nathan Stott
>Assignee: Adam Kocoloski
>Priority: Minor
> Fix For: 1.1
>
> Attachments: couch_httpd_view.erl, multi_start_end_key.diff,
> ranged_key_post.diff
>
>
> It would be useful if I could do a single POST to a view to retrieve multiple
> ranges specified by startkey, endkey.
> The format could be as follows:
> { "ranges": [ { "startkey": "a", "endkey": "c" }, { "startkey":"g",
> "endkey":"z" } ] }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: multi columns
On Wed, Nov 3, 2010 at 12:32 PM, sgoto wrote: > are there any plans for supporting multi columns in couchdb (eg update > one column for a key without re writing the entire row) ? I think it's misleading to refer to CouchDB documents as "rows", since each of them can have a completely unique set of "columns". I suppose every set of attributes on some doc in a database can be considered as the schema for an abstract table containing all the docs with that set of attributes, but it's a bit of a stretch, especially when you get into overlapping attributes. Anyway, CouchDB doesn't have this feature. I disagree with sgoto that the crash-only design prohibits it, however. Certainly the server would have to append the entire modified record to the data store, but that doesn't mean the entire document has to go over the wire back and forth between the server and the client. As long as the modification was anchored to a specific _rev, it would just be shorthand for the GET, PUT sequence currently required. I second the recommendation for MongoDB, which has good support for both in-place document modification and ad-hoc querying. The "reliability and/or deployment complexity" comes down to a few key differences between Couch and Mongo: - Mongo is not crash-only; in fact, a standalone Mongo instance has no reliability guarantees whatsoever. You need to always use clustering if you want to avoid losing or corrupting data. - Clustering is a little more involved to set up than CouchDB replication, and master/master is still experimental - It uses a binary client/server protocol, software for which needs to be installed wherever clients run So it's different, but a good system that might fit your use case better. -- Mark J. Reed
Re: multi columns
On Wed, Nov 3, 2010 at 1:32 PM, sgoto wrote: > hi couchdb, > > are there any plans for supporting multi columns in couchdb (eg update > one column for a key without re writing the entire row) ? I am not a CouchDB guru, but from reading the docs it is clear to me the answer is no. For one thing, your proposed change would break the "crash only" design of CouchDB, one of its best features. See here: """ On-disk, CouchDB never overwrites committed data or associated structures, ensuring the database file is always in a consistent state. This is a “crash-only” design where the CouchDB server does not go through a shut down process, it’s simply terminated. """ http://couchdb.apache.org/docs/overview.html If you want in-place updates, and you are ready to pay its price in terms of reliability and/or deployment complexity, try MongoDB. -- Luciano Ramalho programador repentista || stand-up programmer Twitter: @luciano
CouchDB OTP
Hi everyone, I have a github fork from apache/couchdb https://github.com/tsloughter/couchdb that I modified to be more OTP compliant and now builds with sinan (from http://erlware.org). There wasn't much that I've done so far. I moved the CouchDB app under lib/couchdb. I removed the other apps from the source tree, they can easily be installed with faxien (from http://erlware.org) and versions can be declared if necessary. I changed the _app.erl file to not start applications and added those applications instead to the applications list in the .app file. They will be started properly by the release's boot script. I moved all non-Erlang stuff to lib/couchdb/priv. I still have a number of things to do that I hope to get to tonight. First, fix up the two scripts under bin/. Fix the configuration file locations (some stuff is hardcoded for my environment). Add a hook to sinan to compile the icu driver -- right now I just copied the library over from a build of CouchDB I did separately. There are probably a few other things.. But I was able to do an application:start(couchdb) last night and see it working :). There were a few things I thought of changing within the code as I dug around but those are a separate issue that I'll bring up in discussion after all this is complete. Tristan
Re: Release 1.0.2
and done On Wed, Nov 3, 2010 at 4:55 PM, Filipe David Manana wrote: > Seems fine to me. > Doing it in a few minutes. > > On Wed, Nov 3, 2010 at 4:15 PM, Jan Lehnardt wrote: >> >> On 3 Nov 2010, at 12:13, Filipe David Manana wrote: >> >>> The bug was confirmed by Chandru, and he has already a fix for the >>> next Ibrowse version (not yet on github or public elsewhere). >>> According to him, it shouldn't take more than 1 or 2 days to add it to >>> Ibrowse's public github repository. >>> >>> https://github.com/cmullaparthi/ibrowse/issues/#issue/17 >> >> What do you think about just applying your patch to the current version >> of iBrowse instead of updating to a new version shortly before a CouchDB >> release to ensure it doesn't introduce new issues? — We can then update >> iBrowse in trunk after branching 1.1.x. >> >> Cheers >> Jan >> -- >> >> >> >>> >>> On Tue, Nov 2, 2010 at 9:50 PM, Jan Lehnardt wrote: I agree, let's wait for this one. Cheers Jan -- On 2 Nov 2010, at 21:56, Filipe David Manana wrote: > Unfortunately, I'm now -1 on releasing 1.0.2. > > I've found today a serious issue in ibrowse 2.0 (branch 1.0.x and > trunk). I created a patch and a ticket at github: > > http://github.com/cmullaparthi/ibrowse/issues/#issue/17 > > I would like to wait for an approval from Chandru (ibrowse's author) > before patching our ibrowse version. Hopefully it won't take more than > 1 or 2 days. > > > On Mon, Nov 1, 2010 at 10:27 AM, Filipe David Manana > wrote: >> +1 >> >> On Mon, Nov 1, 2010 at 10:10 AM, Dirkjan Ochtman >> wrote: >>> On Mon, Oct 25, 2010 at 15:12, Jan Lehnardt wrote: How did that go? :) >>> >>> Jan said it was okay for me to continue my apparently weekly nagging >>> for 1.0.2, so consider yourselves nagged. >>> >>> Cheers, >>> >>> Dirkjan >>> >> >> >> >> -- >> Filipe David Manana, >> fdman...@gmail.com, fdman...@apache.org >> >> "Reasonable men adapt themselves to the world. >> Unreasonable men adapt the world to themselves. >> That's why all progress depends on unreasonable men." >> > > > > -- > Filipe David Manana, > fdman...@gmail.com, fdman...@apache.org > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." >>> >>> >>> >>> -- >>> Filipe David Manana, >>> fdman...@gmail.com, fdman...@apache.org >>> >>> "Reasonable men adapt themselves to the world. >>> Unreasonable men adapt the world to themselves. >>> That's why all progress depends on unreasonable men." >> >> > > > > -- > Filipe David Manana, > fdman...@gmail.com, fdman...@apache.org > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." > -- Filipe David Manana, fdman...@gmail.com, fdman...@apache.org "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
Re: Release 1.0.2
Seems fine to me. Doing it in a few minutes. On Wed, Nov 3, 2010 at 4:15 PM, Jan Lehnardt wrote: > > On 3 Nov 2010, at 12:13, Filipe David Manana wrote: > >> The bug was confirmed by Chandru, and he has already a fix for the >> next Ibrowse version (not yet on github or public elsewhere). >> According to him, it shouldn't take more than 1 or 2 days to add it to >> Ibrowse's public github repository. >> >> https://github.com/cmullaparthi/ibrowse/issues/#issue/17 > > What do you think about just applying your patch to the current version > of iBrowse instead of updating to a new version shortly before a CouchDB > release to ensure it doesn't introduce new issues? — We can then update > iBrowse in trunk after branching 1.1.x. > > Cheers > Jan > -- > > > >> >> On Tue, Nov 2, 2010 at 9:50 PM, Jan Lehnardt wrote: >>> I agree, let's wait for this one. >>> >>> Cheers >>> Jan >>> -- >>> >>> On 2 Nov 2010, at 21:56, Filipe David Manana wrote: >>> Unfortunately, I'm now -1 on releasing 1.0.2. I've found today a serious issue in ibrowse 2.0 (branch 1.0.x and trunk). I created a patch and a ticket at github: http://github.com/cmullaparthi/ibrowse/issues/#issue/17 I would like to wait for an approval from Chandru (ibrowse's author) before patching our ibrowse version. Hopefully it won't take more than 1 or 2 days. On Mon, Nov 1, 2010 at 10:27 AM, Filipe David Manana wrote: > +1 > > On Mon, Nov 1, 2010 at 10:10 AM, Dirkjan Ochtman > wrote: >> On Mon, Oct 25, 2010 at 15:12, Jan Lehnardt wrote: >>> How did that go? :) >> >> Jan said it was okay for me to continue my apparently weekly nagging >> for 1.0.2, so consider yourselves nagged. >> >> Cheers, >> >> Dirkjan >> > > > > -- > Filipe David Manana, > fdman...@gmail.com, fdman...@apache.org > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." > -- Filipe David Manana, fdman...@gmail.com, fdman...@apache.org "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." >>> >>> >> >> >> >> -- >> Filipe David Manana, >> fdman...@gmail.com, fdman...@apache.org >> >> "Reasonable men adapt themselves to the world. >> Unreasonable men adapt the world to themselves. >> That's why all progress depends on unreasonable men." > > -- Filipe David Manana, fdman...@gmail.com, fdman...@apache.org "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
[jira] Commented: (COUCHDB-523) View API POST keys to retrieve multiple docs by key could also allow for multiple 'range' queries, i.e. an array of { startkey: .., endkey: ... } params in the POST
[
https://issues.apache.org/jira/browse/COUCHDB-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12927900#action_12927900
]
Anand Chitipothu commented on COUCHDB-523:
--
How about considering a dict instead of a list for queries? Keeping track of
dictionary keys is much easier than keeping track of array indicies.
{
"queries": {
"foo": {"key":"foo"},
"bar": {"startkey":"bar", "endkey":"baz", "limit":10},
...
}
}
And the response will be dictionary with same keys.
{
"results": {
"foo": {"total_rows":100, "offset":34, "rows":[...]},
"bar": {"total_rows":100, "offset":20, "rows":[...]}
}
}
I'm not very sure if introducing another nested level "results" is required,
but it looks symmetrical to the request.
> View API POST keys to retrieve multiple docs by key could also allow for
> multiple 'range' queries, i.e. an array of { startkey: .., endkey: ... }
> params in the POST
>
>
> Key: COUCHDB-523
> URL: https://issues.apache.org/jira/browse/COUCHDB-523
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
>Reporter: Nathan Stott
>Assignee: Adam Kocoloski
>Priority: Minor
> Fix For: 1.1
>
> Attachments: couch_httpd_view.erl, multi_start_end_key.diff,
> ranged_key_post.diff
>
>
> It would be useful if I could do a single POST to a view to retrieve multiple
> ranges specified by startkey, endkey.
> The format could be as follows:
> { "ranges": [ { "startkey": "a", "endkey": "c" }, { "startkey":"g",
> "endkey":"z" } ] }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: multi columns
Hi, Apart from when you use an update handler: http://wiki.apache.org/couchdb/Document_Update_Handlers Cheers Simon On 3 Nov 2010, at 16:34, Sebastian Cohnen wrote: Hey Sam, there are no columns in CouchDB, only documents. And no, you cannot update documents partially with CouchDB. Best Sebastian On 03.11.2010, at 17:32, sgoto wrote: hi couchdb, are there any plans for supporting multi columns in couchdb (eg update one column for a key without re writing the entire row) ? sam -- f u cn rd ths u cn b a gd prgmr !
Re: multi columns
Hey Sam, there are no columns in CouchDB, only documents. And no, you cannot update documents partially with CouchDB. Best Sebastian On 03.11.2010, at 17:32, sgoto wrote: > hi couchdb, > >are there any plans for supporting multi columns in couchdb (eg update > one column for a key without re writing the entire row) ? > >sam > > -- > f u cn rd ths u cn b a gd prgmr !
multi columns
hi couchdb, are there any plans for supporting multi columns in couchdb (eg update one column for a key without re writing the entire row) ? sam -- f u cn rd ths u cn b a gd prgmr !
Re: Release 1.0.2
On 3 Nov 2010, at 12:13, Filipe David Manana wrote: > The bug was confirmed by Chandru, and he has already a fix for the > next Ibrowse version (not yet on github or public elsewhere). > According to him, it shouldn't take more than 1 or 2 days to add it to > Ibrowse's public github repository. > > https://github.com/cmullaparthi/ibrowse/issues/#issue/17 What do you think about just applying your patch to the current version of iBrowse instead of updating to a new version shortly before a CouchDB release to ensure it doesn't introduce new issues? — We can then update iBrowse in trunk after branching 1.1.x. Cheers Jan -- > > On Tue, Nov 2, 2010 at 9:50 PM, Jan Lehnardt wrote: >> I agree, let's wait for this one. >> >> Cheers >> Jan >> -- >> >> On 2 Nov 2010, at 21:56, Filipe David Manana wrote: >> >>> Unfortunately, I'm now -1 on releasing 1.0.2. >>> >>> I've found today a serious issue in ibrowse 2.0 (branch 1.0.x and >>> trunk). I created a patch and a ticket at github: >>> >>> http://github.com/cmullaparthi/ibrowse/issues/#issue/17 >>> >>> I would like to wait for an approval from Chandru (ibrowse's author) >>> before patching our ibrowse version. Hopefully it won't take more than >>> 1 or 2 days. >>> >>> >>> On Mon, Nov 1, 2010 at 10:27 AM, Filipe David Manana >>> wrote: +1 On Mon, Nov 1, 2010 at 10:10 AM, Dirkjan Ochtman wrote: > On Mon, Oct 25, 2010 at 15:12, Jan Lehnardt wrote: >> How did that go? :) > > Jan said it was okay for me to continue my apparently weekly nagging > for 1.0.2, so consider yourselves nagged. > > Cheers, > > Dirkjan > -- Filipe David Manana, fdman...@gmail.com, fdman...@apache.org "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." >>> >>> >>> >>> -- >>> Filipe David Manana, >>> fdman...@gmail.com, fdman...@apache.org >>> >>> "Reasonable men adapt themselves to the world. >>> Unreasonable men adapt the world to themselves. >>> That's why all progress depends on unreasonable men." >> >> > > > > -- > Filipe David Manana, > fdman...@gmail.com, fdman...@apache.org > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men."
Re: [jira] Commented: (COUCHDB-523) View API POST keys to retrieve multiple docs by key could also allow for multiple 'range' queries, i.e. an array of { startkey: .., endkey: ... } params in the POST
I like that. I do something like it in c-l where multiple queries can
be issued and the result becomes an array of responses.
B.
On Wed, Nov 3, 2010 at 10:52 AM, Adam Kocoloski (JIRA) wrote:
>
> [
> https://issues.apache.org/jira/browse/COUCHDB-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12927868#action_12927868
> ]
>
> Adam Kocoloski commented on COUCHDB-523:
>
>
> I've been thinking about this issue a bit and would like to propose an
> alternative syntax. Instead of relying on overloading the "keys" field with
> things that are not really view keys, we could allow a new field called
> "queries" that looks like
>
> {"queries":[{"key":"foo"}, {"startkey":"bar", "endkey":"baz", "limit":10},
> ...]}
>
> That is, each element of the queries Array would be a JSON Object specifying
> view query parameters. Any parameters specified in the actual query string
> would be included as defaults. CouchDB would execute the view requests
> serially and respond with an Array of view responses
>
> [
> {"total_rows":100, "offset":34, "rows":[...]},
> {"total_rows":100, "offset":20, "rows":[...]}
> ]
>
> The "keys" field and the "queries" field would be mutually exclusive. The
> Objects in the queries Array would allow a user to specify any query-string
> parameter used with CouchDB views. I'm not sure if _list functions would be
> supported.
>
> This feature is really a crutch to help HTTP clients that cannot avail
> themselves of advanced HTTP features such as pipelining. I'm happy to add
> it, though, as that the set of clients which do support pipelining is not
> that large.
>
> What do you think?
>
>
>> View API POST keys to retrieve multiple docs by key could also allow for
>> multiple 'range' queries, i.e. an array of { startkey: .., endkey: ... }
>> params in the POST
>>
>>
>> Key: COUCHDB-523
>> URL: https://issues.apache.org/jira/browse/COUCHDB-523
>> Project: CouchDB
>> Issue Type: Improvement
>> Components: HTTP Interface
>> Reporter: Nathan Stott
>> Assignee: Adam Kocoloski
>> Priority: Minor
>> Fix For: 1.1
>>
>> Attachments: couch_httpd_view.erl, multi_start_end_key.diff,
>> ranged_key_post.diff
>>
>>
>> It would be useful if I could do a single POST to a view to retrieve
>> multiple ranges specified by startkey, endkey.
>> The format could be as follows:
>> { "ranges": [ { "startkey": "a", "endkey": "c" }, { "startkey":"g",
>> "endkey":"z" } ] }
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>
[jira] Commented: (COUCHDB-523) View API POST keys to retrieve multiple docs by key could also allow for multiple 'range' queries, i.e. an array of { startkey: .., endkey: ... } params in the POST
[
https://issues.apache.org/jira/browse/COUCHDB-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12927868#action_12927868
]
Adam Kocoloski commented on COUCHDB-523:
I've been thinking about this issue a bit and would like to propose an
alternative syntax. Instead of relying on overloading the "keys" field with
things that are not really view keys, we could allow a new field called
"queries" that looks like
{"queries":[{"key":"foo"}, {"startkey":"bar", "endkey":"baz", "limit":10}, ...]}
That is, each element of the queries Array would be a JSON Object specifying
view query parameters. Any parameters specified in the actual query string
would be included as defaults. CouchDB would execute the view requests
serially and respond with an Array of view responses
[
{"total_rows":100, "offset":34, "rows":[...]},
{"total_rows":100, "offset":20, "rows":[...]}
]
The "keys" field and the "queries" field would be mutually exclusive. The
Objects in the queries Array would allow a user to specify any query-string
parameter used with CouchDB views. I'm not sure if _list functions would be
supported.
This feature is really a crutch to help HTTP clients that cannot avail
themselves of advanced HTTP features such as pipelining. I'm happy to add it,
though, as that the set of clients which do support pipelining is not that
large.
What do you think?
> View API POST keys to retrieve multiple docs by key could also allow for
> multiple 'range' queries, i.e. an array of { startkey: .., endkey: ... }
> params in the POST
>
>
> Key: COUCHDB-523
> URL: https://issues.apache.org/jira/browse/COUCHDB-523
> Project: CouchDB
> Issue Type: Improvement
> Components: HTTP Interface
>Reporter: Nathan Stott
>Assignee: Adam Kocoloski
>Priority: Minor
> Fix For: 1.1
>
> Attachments: couch_httpd_view.erl, multi_start_end_key.diff,
> ranged_key_post.diff
>
>
> It would be useful if I could do a single POST to a view to retrieve multiple
> ranges specified by startkey, endkey.
> The format could be as follows:
> { "ranges": [ { "startkey": "a", "endkey": "c" }, { "startkey":"g",
> "endkey":"z" } ] }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: websockets?
+1 on "websockets a better fit". The exact fit ;) After all, it can go very nice with erlang messaging concept. http://armstrongonsoftware.blogspot.com/2009/12/comet-is-dead-long-live-websockets.html On 2 November 2010 21:22, Dirkjan Ochtman wrote: > On Tue, Nov 2, 2010 at 19:32, Jan Lehnardt wrote: >> Can you qualify "better fit". Not trying to throw stones your way, but >> what exactly makes it better in your view? (Maybe all I need is a link >> to the ticket :) > > I don't think there's much in the ticket. > > It seems to me that HTTP is fundamentally a request-response protocol. > You can do multiple requests over a single connection, but that's not > what the changes feed does. The way HTTP is used for the changes feed > seems to be, "here's this response that never ends, be sure to poll it > once in a while to see if it's grown". On the other hand, the > WebSocket model seems to fundamentally be about sending small(er) > chunks of data between HTTP server and client, which seems to be a > better fit for the continuous changes feed conceptually, and would > probably make accepting those chunks from JS running in a browser and > updating your page state with them much easier, just because now we're > talking about small chunk events instead of a growing response > document. > > Cheers, > > Dirkjan > -- DU
Re: Release 1.0.2
The bug was confirmed by Chandru, and he has already a fix for the next Ibrowse version (not yet on github or public elsewhere). According to him, it shouldn't take more than 1 or 2 days to add it to Ibrowse's public github repository. https://github.com/cmullaparthi/ibrowse/issues/#issue/17 On Tue, Nov 2, 2010 at 9:50 PM, Jan Lehnardt wrote: > I agree, let's wait for this one. > > Cheers > Jan > -- > > On 2 Nov 2010, at 21:56, Filipe David Manana wrote: > >> Unfortunately, I'm now -1 on releasing 1.0.2. >> >> I've found today a serious issue in ibrowse 2.0 (branch 1.0.x and >> trunk). I created a patch and a ticket at github: >> >> http://github.com/cmullaparthi/ibrowse/issues/#issue/17 >> >> I would like to wait for an approval from Chandru (ibrowse's author) >> before patching our ibrowse version. Hopefully it won't take more than >> 1 or 2 days. >> >> >> On Mon, Nov 1, 2010 at 10:27 AM, Filipe David Manana >> wrote: >>> +1 >>> >>> On Mon, Nov 1, 2010 at 10:10 AM, Dirkjan Ochtman wrote: On Mon, Oct 25, 2010 at 15:12, Jan Lehnardt wrote: > How did that go? :) Jan said it was okay for me to continue my apparently weekly nagging for 1.0.2, so consider yourselves nagged. Cheers, Dirkjan >>> >>> >>> >>> -- >>> Filipe David Manana, >>> fdman...@gmail.com, fdman...@apache.org >>> >>> "Reasonable men adapt themselves to the world. >>> Unreasonable men adapt the world to themselves. >>> That's why all progress depends on unreasonable men." >>> >> >> >> >> -- >> Filipe David Manana, >> fdman...@gmail.com, fdman...@apache.org >> >> "Reasonable men adapt themselves to the world. >> Unreasonable men adapt the world to themselves. >> That's why all progress depends on unreasonable men." > > -- Filipe David Manana, fdman...@gmail.com, fdman...@apache.org "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
[jira] Closed: (COUCHDB-932) create_target CreateDB PUT request fails
[ https://issues.apache.org/jira/browse/COUCHDB-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana closed COUCHDB-932. - Resolution: Fixed Committed to trunk and 1.0.x. I only left out the unrelated change to the test design_docs.js. (Which was already in trunk btw). Thanks Dale. > create_target CreateDB PUT request fails > > > Key: COUCHDB-932 > URL: https://issues.apache.org/jira/browse/COUCHDB-932 > Project: CouchDB > Issue Type: Bug > Components: Replication > Environment: On a Mobile Broadband Connection >Reporter: Dale Harvey > Attachments: anon.patch > > > Some proxies (for mobile broadband providers) require Content-Length to set > for all PUT requests -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
