documentation of couchdb internals?

[Miles Fidelman]

Hi Folks,

Can anybody point me at a good presentation on the internals of couchdb?

I'm really interested in how couch makes use of erlang's actor model.

I've done a lot of googling, and can't seem to find a "theory of 
operations" or architectural overview.  Perhaps someone here knows of one?


Thanks very much,

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

Re: Is this mailing list obsolete now?

[Miles Fidelman]

Well, as a user, I kind of find that the move to a github discussion is 
not at all helpful.  Email lists are a time-proven mechanism - why break 
what ain't broke.


Miles Fidelman

On 7/12/20 3:43 PM, Kiril Stankov wrote:

Hi,

I see that some topics on the list are not in the github discussions and
vice versa?

Shall we all consider the mailing list obsolete and move to github?

Is there a way to get summaries from github or other kind of
notifications by email?

Cheers,

Kiril.


--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

Re: scaling?

[Miles Fidelman]

On 5/24/20 11:42 AM, Jan Lehnardt wrote:



On 24. May 2020, at 17:32, Miles Fidelman  wrote:

Thanks Jan, and a follow-up, below:

On 5/24/20 4:51 AM, Jan Lehnardt wrote:

On 23. May 2020, at 18:57, Miles Fidelman  wrote:

On 5/23/20 12:29 PM, Jan Lehnardt wrote:


On 23. May 2020, at 16:28, Miles Fidelman  wrote:


On 5/22/20 11:13 AM, Jan Lehnardt wrote:


On 22. May 2020, at 15:06, Miles Fidelman  wrote:

Hi Jan,

On 5/22/20 6:17 AM, Jan Lehnardt wrote:

Hi Miles,

I wanted to reply for a while, but struggled to find a good angle. I think I 
finally figured out what I missed. I’m not sure I understand your deployment 
scenario.

When I think conference app, I think folks having that on their mobile phones, 
or tablets. Given that, you’d be using PouchDB (for web apps) or one of 
Cloudant mobile sync libraries (if it is a native app). Either way, to get the 
data to the devices, it’d have to come from somewhere, but then you say there 
is no central server. Where does the data come from?

I was using that as an example - but I'm really thinking more the case of "smart 
documents." Think of a plan (business, mission) or briefing package - and the whole 
notion of "living documents.

not sure what these are and how they compare to CouchDB documents.

"Living Document" as in writerspeak - a binder full of documentation that is 
continually being kept up to date, the latest version of a proposal, a book draft, a 
theatrical script that's being marked up with commentary during rehearsal, etc.

Or think of marrying a wiki to a DCVS.


It sounds like you imagine the devices talking to each other in a replication 
mesh kind of way. While technically possible from a CouchDB replication 
protocol point of view, this approach isn’t very practical. For one, you won’t 
be able to guarantee that all devices can talk to each other, especially when 
you don’t control the wifi.

What’s more likely is that you’d have central CouchDB server that is connected 
to the wifi network, either on site, or in a datacenter somewhere that all 
devices connect to.

Having that many devices talk to a central database to get all the relatively 
static data of the conference (schedule, info, etc), doesn’t sound like much of 
a problem. Group interaction is a little more interesting. You could model this 
a 1-db-per-group, and it would work okay, but there are some 
devil-in-the-details-details to work out with access control and joining and 
leaving a group, etc.

So overall:

- what architecture do you envision?
- I think this can be made to work.
- CouchDB definitely can handle 5000 intermittent clients. Depending on your 
use-case, you may need more or less computing resources for this, but there 
aren’t any fundamental blockers in CouchDB’s design that would prevent this 
from being a success.

I keep coming back to the model of replicated copies, stored in something like a distributed 
version control system, linked by a publish-subscribe network. (Not that much different than 
the way large-scale modeling & sims are done - local "world models" linked by a 
protocol like DIS or HLA.)

I've been wondering if Couch/Pouch might make a good platform - coupled with 
something like NNTP for epidemic style distribution of changes.

If you squint a little, CouchDB fits your buzzword bill here, but without more 
concrete descriptions of what you need (rather than less), we can’t help much.

And you didn’t address the network connectivity issue. If you plan to have 
device-to-device communication, and you are not Apple or Google making those 
devices and/or mobile operating systems, you won’t be having much luck, 
especially on the web platform.

I'm thinking tactical environments & mesh networks, with intermittent 
connectivity.  Updates propagate slowly, but with either automatic fork/merge, or 
with eventual consistency.

Right, so far the theory, which the CouchDB replication protocol supports. Now 
in practice, say you are using PouchDB, how do you make one device’s browser 
talk to another device’s browser?

Well... I would see this as a case of mesh networking.  An instance of PouchDB, 
on a phone, might sync to one (or more) instances of CouchDB - running on a 
laptop, or a server.  The basic model would be that of NNTP.  Updates would 
ripple through a mesh of instances.  My assumption is, that any particular 
instance of Couch of Pouch needs to know one or more other instances to connect 
to - and from there, stuff moves around.

that is more concrete and we can talk about it now, thanks for clarifying.


Which comes back to... how well does this scale?  What's the largest mesh 
network of Pouch/Couch instances that anybody has run in practice?

since the setup is very non-standard, there isn’t a lot of existing setups to 
look for.

I know of a PouchDB-running-inside-node.js on IoT devices scenario covering a 
large geographic area with mesh wifi, collecting data and replicating sen

Re: scaling?

[Miles Fidelman]

Thanks Jan, and a follow-up, below:

On 5/24/20 4:51 AM, Jan Lehnardt wrote:



On 23. May 2020, at 18:57, Miles Fidelman  wrote:

On 5/23/20 12:29 PM, Jan Lehnardt wrote:


On 23. May 2020, at 16:28, Miles Fidelman  wrote:


On 5/22/20 11:13 AM, Jan Lehnardt wrote:


On 22. May 2020, at 15:06, Miles Fidelman  wrote:

Hi Jan,

On 5/22/20 6:17 AM, Jan Lehnardt wrote:

Hi Miles,

I wanted to reply for a while, but struggled to find a good angle. I think I 
finally figured out what I missed. I’m not sure I understand your deployment 
scenario.

When I think conference app, I think folks having that on their mobile phones, 
or tablets. Given that, you’d be using PouchDB (for web apps) or one of 
Cloudant mobile sync libraries (if it is a native app). Either way, to get the 
data to the devices, it’d have to come from somewhere, but then you say there 
is no central server. Where does the data come from?

I was using that as an example - but I'm really thinking more the case of "smart 
documents." Think of a plan (business, mission) or briefing package - and the whole 
notion of "living documents.

not sure what these are and how they compare to CouchDB documents.

"Living Document" as in writerspeak - a binder full of documentation that is 
continually being kept up to date, the latest version of a proposal, a book draft, a 
theatrical script that's being marked up with commentary during rehearsal, etc.

Or think of marrying a wiki to a DCVS.


It sounds like you imagine the devices talking to each other in a replication 
mesh kind of way. While technically possible from a CouchDB replication 
protocol point of view, this approach isn’t very practical. For one, you won’t 
be able to guarantee that all devices can talk to each other, especially when 
you don’t control the wifi.

What’s more likely is that you’d have central CouchDB server that is connected 
to the wifi network, either on site, or in a datacenter somewhere that all 
devices connect to.

Having that many devices talk to a central database to get all the relatively 
static data of the conference (schedule, info, etc), doesn’t sound like much of 
a problem. Group interaction is a little more interesting. You could model this 
a 1-db-per-group, and it would work okay, but there are some 
devil-in-the-details-details to work out with access control and joining and 
leaving a group, etc.

So overall:

- what architecture do you envision?
- I think this can be made to work.
- CouchDB definitely can handle 5000 intermittent clients. Depending on your 
use-case, you may need more or less computing resources for this, but there 
aren’t any fundamental blockers in CouchDB’s design that would prevent this 
from being a success.

I keep coming back to the model of replicated copies, stored in something like a distributed 
version control system, linked by a publish-subscribe network. (Not that much different than 
the way large-scale modeling & sims are done - local "world models" linked by a 
protocol like DIS or HLA.)

I've been wondering if Couch/Pouch might make a good platform - coupled with 
something like NNTP for epidemic style distribution of changes.

If you squint a little, CouchDB fits your buzzword bill here, but without more 
concrete descriptions of what you need (rather than less), we can’t help much.

And you didn’t address the network connectivity issue. If you plan to have 
device-to-device communication, and you are not Apple or Google making those 
devices and/or mobile operating systems, you won’t be having much luck, 
especially on the web platform.

I'm thinking tactical environments & mesh networks, with intermittent 
connectivity.  Updates propagate slowly, but with either automatic fork/merge, or 
with eventual consistency.

Right, so far the theory, which the CouchDB replication protocol supports. Now 
in practice, say you are using PouchDB, how do you make one device’s browser 
talk to another device’s browser?

Well... I would see this as a case of mesh networking.  An instance of PouchDB, 
on a phone, might sync to one (or more) instances of CouchDB - running on a 
laptop, or a server.  The basic model would be that of NNTP.  Updates would 
ripple through a mesh of instances.  My assumption is, that any particular 
instance of Couch of Pouch needs to know one or more other instances to connect 
to - and from there, stuff moves around.

that is more concrete and we can talk about it now, thanks for clarifying.


Which comes back to... how well does this scale?  What's the largest mesh 
network of Pouch/Couch instances that anybody has run in practice?

since the setup is very non-standard, there isn’t a lot of existing setups to 
look for.

I know of a PouchDB-running-inside-node.js on IoT devices scenario covering a 
large geographic area with mesh wifi, collecting data and replicating sensory 
data through the mesh up to one point that has an internet uplink, which then 
sends the

Re: scaling?

[Miles Fidelman]

On 5/23/20 12:29 PM, Jan Lehnardt wrote:




On 23. May 2020, at 16:28, Miles Fidelman  wrote:


On 5/22/20 11:13 AM, Jan Lehnardt wrote:


On 22. May 2020, at 15:06, Miles Fidelman  wrote:

Hi Jan,

On 5/22/20 6:17 AM, Jan Lehnardt wrote:

Hi Miles,

I wanted to reply for a while, but struggled to find a good angle. I think I 
finally figured out what I missed. I’m not sure I understand your deployment 
scenario.

When I think conference app, I think folks having that on their mobile phones, 
or tablets. Given that, you’d be using PouchDB (for web apps) or one of 
Cloudant mobile sync libraries (if it is a native app). Either way, to get the 
data to the devices, it’d have to come from somewhere, but then you say there 
is no central server. Where does the data come from?

I was using that as an example - but I'm really thinking more the case of "smart 
documents." Think of a plan (business, mission) or briefing package - and the whole 
notion of "living documents.

not sure what these are and how they compare to CouchDB documents.

"Living Document" as in writerspeak - a binder full of documentation that is 
continually being kept up to date, the latest version of a proposal, a book draft, a 
theatrical script that's being marked up with commentary during rehearsal, etc.

Or think of marrying a wiki to a DCVS.


It sounds like you imagine the devices talking to each other in a replication 
mesh kind of way. While technically possible from a CouchDB replication 
protocol point of view, this approach isn’t very practical. For one, you won’t 
be able to guarantee that all devices can talk to each other, especially when 
you don’t control the wifi.

What’s more likely is that you’d have central CouchDB server that is connected 
to the wifi network, either on site, or in a datacenter somewhere that all 
devices connect to.

Having that many devices talk to a central database to get all the relatively 
static data of the conference (schedule, info, etc), doesn’t sound like much of 
a problem. Group interaction is a little more interesting. You could model this 
a 1-db-per-group, and it would work okay, but there are some 
devil-in-the-details-details to work out with access control and joining and 
leaving a group, etc.

So overall:

- what architecture do you envision?
- I think this can be made to work.
- CouchDB definitely can handle 5000 intermittent clients. Depending on your 
use-case, you may need more or less computing resources for this, but there 
aren’t any fundamental blockers in CouchDB’s design that would prevent this 
from being a success.

I keep coming back to the model of replicated copies, stored in something like a distributed 
version control system, linked by a publish-subscribe network. (Not that much different than 
the way large-scale modeling & sims are done - local "world models" linked by a 
protocol like DIS or HLA.)

I've been wondering if Couch/Pouch might make a good platform - coupled with 
something like NNTP for epidemic style distribution of changes.

If you squint a little, CouchDB fits your buzzword bill here, but without more 
concrete descriptions of what you need (rather than less), we can’t help much.

And you didn’t address the network connectivity issue. If you plan to have 
device-to-device communication, and you are not Apple or Google making those 
devices and/or mobile operating systems, you won’t be having much luck, 
especially on the web platform.

I'm thinking tactical environments & mesh networks, with intermittent 
connectivity.  Updates propagate slowly, but with either automatic fork/merge, or 
with eventual consistency.

Right, so far the theory, which the CouchDB replication protocol supports. Now 
in practice, say you are using PouchDB, how do you make one device’s browser 
talk to another device’s browser?


Well... I would see this as a case of mesh networking.  An instance of 
PouchDB, on a phone, might sync to one (or more) instances of CouchDB - 
running on a laptop, or a server.  The basic model would be that of 
NNTP.  Updates would ripple through a mesh of instances.  My assumption 
is, that any particular instance of Couch of Pouch needs to know one or 
more other instances to connect to - and from there, stuff moves around.


Which comes back to... how well does this scale?  What's the largest 
mesh network of Pouch/Couch instances that anybody has run in practice?


Miles






Best
Jan
—


Cheers,

Miles



Best
Jan
—


Miles



Best
Jan
—


On 20. May 2020, at 14:23, Miles Fidelman  wrote:

Hi Folks,

I'm thinking of using Couch (or Couch plus Pouch) as the platform for a 
conference program app - everyone gets their copy of the program, plus 
handouts/proceedings, with the added capabilities to set up one's personal 
schedule, hold side conversations with various groups, schedule BOF meetings, 
etc.

Which leads me to wonder what experience folks have had with scaling - 
particularly wit

Re: scaling?

[Miles Fidelman]

On 5/22/20 11:13 AM, Jan Lehnardt wrote:



On 22. May 2020, at 15:06, Miles Fidelman 
 wrote:


Hi Jan,

On 5/22/20 6:17 AM, Jan Lehnardt wrote:

Hi Miles,

I wanted to reply for a while, but struggled to find a good angle. I 
think I finally figured out what I missed. I’m not sure I understand 
your deployment scenario.


When I think conference app, I think folks having that on their 
mobile phones, or tablets. Given that, you’d be using PouchDB (for 
web apps) or one of Cloudant mobile sync libraries (if it is a 
native app). Either way, to get the data to the devices, it’d have 
to come from somewhere, but then you say there is no central server. 
Where does the data come from?
I was using that as an example - but I'm really thinking more the 
case of "smart documents." Think of a plan (business, mission) or 
briefing package - and the whole notion of "living documents.

not sure what these are and how they compare to CouchDB documents.


"Living Document" as in writerspeak - a binder full of documentation 
that is continually being kept up to date, the latest version of a 
proposal, a book draft, a theatrical script that's being marked up with 
commentary during rehearsal, etc.


Or think of marrying a wiki to a DCVS.





It sounds like you imagine the devices talking to each other in a 
replication mesh kind of way. While technically possible from a 
CouchDB replication protocol point of view, this approach isn’t very 
practical. For one, you won’t be able to guarantee that all devices 
can talk to each other, especially when you don’t control the wifi.


What’s more likely is that you’d have central CouchDB server that is 
connected to the wifi network, either on site, or in a datacenter 
somewhere that all devices connect to.


Having that many devices talk to a central database to get all the 
relatively static data of the conference (schedule, info, etc), 
doesn’t sound like much of a problem. Group interaction is a little 
more interesting. You could model this a 1-db-per-group, and it 
would work okay, but there are some devil-in-the-details-details to 
work out with access control and joining and leaving a group, etc.


So overall:

- what architecture do you envision?
- I think this can be made to work.
- CouchDB definitely can handle 5000 intermittent clients. Depending 
on your use-case, you may need more or less computing resources for 
this, but there aren’t any fundamental blockers in CouchDB’s design 
that would prevent this from being a success.
I keep coming back to the model of replicated copies, stored in 
something like a distributed version control system, linked by a 
publish-subscribe network. (Not that much different than the way 
large-scale modeling & sims are done - local "world models" linked by 
a protocol like DIS or HLA.)


I've been wondering if Couch/Pouch might make a good platform - 
coupled with something like NNTP for epidemic style distribution of 
changes.
If you squint a little, CouchDB fits your buzzword bill here, but 
without more concrete descriptions of what you need (rather than 
less), we can’t help much.


And you didn’t address the network connectivity issue. If you plan to 
have device-to-device communication, and you are not Apple or Google 
making those devices and/or mobile operating systems, you won’t be 
having much luck, especially on the web platform.


I'm thinking tactical environments & mesh networks, with intermittent 
connectivity.  Updates propagate slowly, but with either automatic 
fork/merge, or with eventual consistency.


Cheers,

Miles




Best
Jan
—


Miles



Best
Jan
—

On 20. May 2020, at 14:23, Miles Fidelman 
 wrote:


Hi Folks,

I'm thinking of using Couch (or Couch plus Pouch) as the platform 
for a conference program app - everyone gets their copy of the 
program, plus handouts/proceedings, with the added capabilities to 
set up one's personal schedule, hold side conversations with 
various groups, schedule BOF meetings, etc.


Which leads me to wonder what experience folks have had with 
scaling - particularly without using a central server. Can, say, 
5000 instances, linked intermittently, stay reasonably consistent?


What's the largest collection of Couch instances anybody has played 
with?


Thanks,

Miles Fidelman

-- In theory, there is no difference between theory and practice.
In practice, there is.  Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why. ... unknown


-- In theory, there is no difference between theory and practice.
In practice, there is.  Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why. ... unknown


--
In theory, there is no differen

Re: scaling?

[Miles Fidelman]

Hi Jan,

On 5/22/20 6:17 AM, Jan Lehnardt wrote:

Hi Miles,

I wanted to reply for a while, but struggled to find a good angle. I think I 
finally figured out what I missed. I’m not sure I understand your deployment 
scenario.

When I think conference app, I think folks having that on their mobile phones, 
or tablets. Given that, you’d be using PouchDB (for web apps) or one of 
Cloudant mobile sync libraries (if it is a native app). Either way, to get the 
data to the devices, it’d have to come from somewhere, but then you say there 
is no central server. Where does the data come from?


I was using that as an example - but I'm really thinking more the case 
of "smart documents."  Think of a plan (business, mission) or briefing 
package - and the whole notion of "living documents.




It sounds like you imagine the devices talking to each other in a replication 
mesh kind of way. While technically possible from a CouchDB replication 
protocol point of view, this approach isn’t very practical. For one, you won’t 
be able to guarantee that all devices can talk to each other, especially when 
you don’t control the wifi.

What’s more likely is that you’d have central CouchDB server that is connected 
to the wifi network, either on site, or in a datacenter somewhere that all 
devices connect to.

Having that many devices talk to a central database to get all the relatively 
static data of the conference (schedule, info, etc), doesn’t sound like much of 
a problem. Group interaction is a little more interesting. You could model this 
a 1-db-per-group, and it would work okay, but there are some 
devil-in-the-details-details to work out with access control and joining and 
leaving a group, etc.

So overall:

- what architecture do you envision?
- I think this can be made to work.
- CouchDB definitely can handle 5000 intermittent clients. Depending on your 
use-case, you may need more or less computing resources for this, but there 
aren’t any fundamental blockers in CouchDB’s design that would prevent this 
from being a success.


I keep coming back to the model of replicated copies, stored in 
something like a distributed version control system, linked by a 
publish-subscribe network.  (Not that much different than the way 
large-scale modeling & sims are done - local "world models" linked by a 
protocol like DIS or HLA.)


I've been wondering if Couch/Pouch might make a good platform - coupled 
with something like NNTP for epidemic style distribution of changes.


Miles




Best
Jan
—


On 20. May 2020, at 14:23, Miles Fidelman  wrote:

Hi Folks,

I'm thinking of using Couch (or Couch plus Pouch) as the platform for a 
conference program app - everyone gets their copy of the program, plus 
handouts/proceedings, with the added capabilities to set up one's personal 
schedule, hold side conversations with various groups, schedule BOF meetings, 
etc.

Which leads me to wonder what experience folks have had with scaling - 
particularly without using a central server.  Can, say, 5000 instances, linked 
intermittently, stay reasonably consistent?

What's the largest collection of Couch instances anybody has played with?

Thanks,

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown


--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

scaling?

[Miles Fidelman]

Hi Folks,

I'm thinking of using Couch (or Couch plus Pouch) as the platform for a 
conference program app - everyone gets their copy of the program, plus 
handouts/proceedings, with the added capabilities to set up one's 
personal schedule, hold side conversations with various groups, schedule 
BOF meetings, etc.


Which leads me to wonder what experience folks have had with scaling - 
particularly without using a central server.  Can, say, 5000 instances, 
linked intermittently, stay reasonably consistent?


What's the largest collection of Couch instances anybody has played with?

Thanks,

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Theory is when you know everything but nothing works.
Practice is when everything works but no one knows why.
In our lab, theory and practice are combined:
nothing works and no one knows why.  ... unknown

Re: replicated blog engine?

[Miles Fidelman]

Thanks!

On 2/4/19 4:53 PM, Bill Stephenson wrote:

PouchDB evolved very quickly in the past few years, so it’s worth another look. 
It seems to have stalled at the 7.0 version for close to the past year, but 
it’s a solid toolset with a nice API to interact with CouchDB.

Running PouchDB in Node.js provides that same API on the server side to 
interact CouchDB. I wrote my comments feature in Perl because you have to 
restrict what users can do with that feature. It could be done just as easily, 
or maybe even easier, using JS and Node running on the server side and when you 
look at it that way there’s very little difference between using Perl or Python 
or JS, except that most of the Perl modules on CPAN for CouchDB are pretty old 
and crappy, and PouchDB is pretty sweet and easy.

I’ve just not mess with Node.js much, and I already know a bit of Perl.

Bill





On Feb 4, 2019, at 3:36 PM, Bill Stephenson  wrote:

Look into the PouchDB API:

https://pouchdb.com/api.html#replication

And check into the CouchDB docs on replication. These are made to work together.

You can probably trigger a replication a number of ways. As far as I know 
though, it’s not uncommon to use PouchDB on a server to manage CouchDBs on the 
same and remote servers.

Kindest Regards,

Bill






On Feb 4, 2019, at 3:18 PM, Miles Fidelman  wrote:

Now that just seems silly.  If CouchDB is already running, who needs Pouch?

On 2/4/19 4:12 PM, Bill Stephenson wrote:

You can run PouchDB on the server side in Node.js. An instance of that could be 
configured to live sync remote CouchDBs

Kindest Regards,

Bill Stephenson
Tech Support
www.cherrypc.com <http://www.ezinvoice.com/>
1-417-546-8390





On Feb 4, 2019, at 3:10 PM, Miles Fidelman  wrote:

I'm thinking more of sync across multiple CouchDB back-ends.  I'm really not 
looking for a solution that runs completely in a browser, without installing 
PouchDB.

On 2/4/19 4:05 PM, Bill Stephenson wrote:

Yes, using PouchDB on the client side you can configure the text.js  (the 
“publisher app) to “live sync” the changes on their local db to your CouchDB, 
which will then sync all the connected clients.

When a user views a post with the blog app, the app grabs the post from the 
CouchDB, so they always get the latest version.

You can check out an example of the live sync feature with the “Todo” app. Run 
it in two or more web browsers at the same time, make changes in one of them 
and you’ll see the changes appear in the others almost instantly.


Bill




On Feb 4, 2019, at 2:55 PM, Miles Fidelman  wrote:

And that will replicate to other couchdb instances hosting the page?

Miles

On 2/4/19 3:47 PM, Bill Stephenson wrote:

Yes, viewer comments are added to the blog post doc with a perl script running 
on the server side.

I’d be glad to send you the script.

Kindest Regards,

Bill Stephenson
Tech Support
www.cherrypc.com <http://www.ezinvoice.com/>
1-417-546-8390





On Feb 4, 2019, at 2:41 PM, Miles Fidelman  wrote:

Martin & Bill - thanks for your replies & pointers!  Both look interesting.

Bill - a follow-up:  Does the single page blog, at azartiz.com, support replication 
of comments?  My goal is to publish a blog, distribute it to various social media 
sites, and build a single discussion community around each post.  I prefer to take 
a replicated approach for the database, on general principles (reliability and 
such).  Essentially, publish via RSS, with each post & associated comments 
becoming their own mesh network.

Thanks Again,

Miles

On 2/4/19 1:24 PM, Bill Stephenson wrote:

I’m not sure if it qualifies, but you’re welcome to take a look the blog I've 
made at azartiz.com.

Kindest Regards,

Bill Stephenson






On Feb 4, 2019, at 12:20 PM, Miles Fidelman  wrote:

Hi Folks,

I wonder if anybody has built a replicated blog engine on top of CouchDB - 
something like WordPress that can run as multiple, synchronized, local copies.

Anybody know of such a beast?

Thanks very much,

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra



--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: replicated blog engine?

[Miles Fidelman]

Well, ok - but last time I looked (admittedly a while), PouchDB was 
basically intended to be a CouchDB equivalent that would run on a device 
that wouldn't support a full-blown CouchDB installation (e.g., a 
smartphone).


I still like the old CouchAPP model - singlepage apps that could be 
stored in CouchDB, accessed via a browser, with a CouchDB backend.


Thanks,

Miles

On 2/4/19 4:36 PM, Bill Stephenson wrote:

Look into the PouchDB API:

https://pouchdb.com/api.html#replication

And check into the CouchDB docs on replication. These are made to work together.

You can probably trigger a replication a number of ways. As far as I know 
though, it’s not uncommon to use PouchDB on a server to manage CouchDBs on the 
same and remote servers.

Kindest Regards,

Bill






On Feb 4, 2019, at 3:18 PM, Miles Fidelman  wrote:

Now that just seems silly.  If CouchDB is already running, who needs Pouch?

On 2/4/19 4:12 PM, Bill Stephenson wrote:

You can run PouchDB on the server side in Node.js. An instance of that could be 
configured to live sync remote CouchDBs

Kindest Regards,

Bill Stephenson
Tech Support
www.cherrypc.com <http://www.ezinvoice.com/>
1-417-546-8390





On Feb 4, 2019, at 3:10 PM, Miles Fidelman  wrote:

I'm thinking more of sync across multiple CouchDB back-ends.  I'm really not 
looking for a solution that runs completely in a browser, without installing 
PouchDB.

On 2/4/19 4:05 PM, Bill Stephenson wrote:

Yes, using PouchDB on the client side you can configure the text.js  (the 
“publisher app) to “live sync” the changes on their local db to your CouchDB, 
which will then sync all the connected clients.

When a user views a post with the blog app, the app grabs the post from the 
CouchDB, so they always get the latest version.

You can check out an example of the live sync feature with the “Todo” app. Run 
it in two or more web browsers at the same time, make changes in one of them 
and you’ll see the changes appear in the others almost instantly.


Bill




On Feb 4, 2019, at 2:55 PM, Miles Fidelman  wrote:

And that will replicate to other couchdb instances hosting the page?

Miles

On 2/4/19 3:47 PM, Bill Stephenson wrote:

Yes, viewer comments are added to the blog post doc with a perl script running 
on the server side.

I’d be glad to send you the script.

Kindest Regards,

Bill Stephenson
Tech Support
www.cherrypc.com <http://www.ezinvoice.com/>
1-417-546-8390





On Feb 4, 2019, at 2:41 PM, Miles Fidelman  wrote:

Martin & Bill - thanks for your replies & pointers!  Both look interesting.

Bill - a follow-up:  Does the single page blog, at azartiz.com, support replication 
of comments?  My goal is to publish a blog, distribute it to various social media 
sites, and build a single discussion community around each post.  I prefer to take 
a replicated approach for the database, on general principles (reliability and 
such).  Essentially, publish via RSS, with each post & associated comments 
becoming their own mesh network.

Thanks Again,

Miles

On 2/4/19 1:24 PM, Bill Stephenson wrote:

I’m not sure if it qualifies, but you’re welcome to take a look the blog I've 
made at azartiz.com.

Kindest Regards,

Bill Stephenson






On Feb 4, 2019, at 12:20 PM, Miles Fidelman  wrote:

Hi Folks,

I wonder if anybody has built a replicated blog engine on top of CouchDB - 
something like WordPress that can run as multiple, synchronized, local copies.

Anybody know of such a beast?

Thanks very much,

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra



--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: replicated blog engine?

[Miles Fidelman]

Now that just seems silly.  If CouchDB is already running, who needs Pouch?

On 2/4/19 4:12 PM, Bill Stephenson wrote:

You can run PouchDB on the server side in Node.js. An instance of that could be 
configured to live sync remote CouchDBs

Kindest Regards,

Bill Stephenson
Tech Support
www.cherrypc.com <http://www.ezinvoice.com/>
1-417-546-8390





On Feb 4, 2019, at 3:10 PM, Miles Fidelman  wrote:

I'm thinking more of sync across multiple CouchDB back-ends.  I'm really not 
looking for a solution that runs completely in a browser, without installing 
PouchDB.

On 2/4/19 4:05 PM, Bill Stephenson wrote:

Yes, using PouchDB on the client side you can configure the text.js  (the 
“publisher app) to “live sync” the changes on their local db to your CouchDB, 
which will then sync all the connected clients.

When a user views a post with the blog app, the app grabs the post from the 
CouchDB, so they always get the latest version.

You can check out an example of the live sync feature with the “Todo” app. Run 
it in two or more web browsers at the same time, make changes in one of them 
and you’ll see the changes appear in the others almost instantly.


Bill




On Feb 4, 2019, at 2:55 PM, Miles Fidelman  wrote:

And that will replicate to other couchdb instances hosting the page?

Miles

On 2/4/19 3:47 PM, Bill Stephenson wrote:

Yes, viewer comments are added to the blog post doc with a perl script running 
on the server side.

I’d be glad to send you the script.

Kindest Regards,

Bill Stephenson
Tech Support
www.cherrypc.com <http://www.ezinvoice.com/>
1-417-546-8390





On Feb 4, 2019, at 2:41 PM, Miles Fidelman  wrote:

Martin & Bill - thanks for your replies & pointers!  Both look interesting.

Bill - a follow-up:  Does the single page blog, at azartiz.com, support replication 
of comments?  My goal is to publish a blog, distribute it to various social media 
sites, and build a single discussion community around each post.  I prefer to take 
a replicated approach for the database, on general principles (reliability and 
such).  Essentially, publish via RSS, with each post & associated comments 
becoming their own mesh network.

Thanks Again,

Miles

On 2/4/19 1:24 PM, Bill Stephenson wrote:

I’m not sure if it qualifies, but you’re welcome to take a look the blog I've 
made at azartiz.com.

Kindest Regards,

Bill Stephenson






On Feb 4, 2019, at 12:20 PM, Miles Fidelman  wrote:

Hi Folks,

I wonder if anybody has built a replicated blog engine on top of CouchDB - 
something like WordPress that can run as multiple, synchronized, local copies.

Anybody know of such a beast?

Thanks very much,

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra



--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: replicated blog engine?

[Miles Fidelman]

I'm thinking more of sync across multiple CouchDB back-ends.  I'm really 
not looking for a solution that runs completely in a browser, without 
installing PouchDB.


On 2/4/19 4:05 PM, Bill Stephenson wrote:

Yes, using PouchDB on the client side you can configure the text.js  (the 
“publisher app) to “live sync” the changes on their local db to your CouchDB, 
which will then sync all the connected clients.

When a user views a post with the blog app, the app grabs the post from the 
CouchDB, so they always get the latest version.

You can check out an example of the live sync feature with the “Todo” app. Run 
it in two or more web browsers at the same time, make changes in one of them 
and you’ll see the changes appear in the others almost instantly.


Bill




On Feb 4, 2019, at 2:55 PM, Miles Fidelman  wrote:

And that will replicate to other couchdb instances hosting the page?

Miles

On 2/4/19 3:47 PM, Bill Stephenson wrote:

Yes, viewer comments are added to the blog post doc with a perl script running 
on the server side.

I’d be glad to send you the script.

Kindest Regards,

Bill Stephenson
Tech Support
www.cherrypc.com <http://www.ezinvoice.com/>
1-417-546-8390





On Feb 4, 2019, at 2:41 PM, Miles Fidelman  wrote:

Martin & Bill - thanks for your replies & pointers!  Both look interesting.

Bill - a follow-up:  Does the single page blog, at azartiz.com, support replication 
of comments?  My goal is to publish a blog, distribute it to various social media 
sites, and build a single discussion community around each post.  I prefer to take 
a replicated approach for the database, on general principles (reliability and 
such).  Essentially, publish via RSS, with each post & associated comments 
becoming their own mesh network.

Thanks Again,

Miles

On 2/4/19 1:24 PM, Bill Stephenson wrote:

I’m not sure if it qualifies, but you’re welcome to take a look the blog I've 
made at azartiz.com.

Kindest Regards,

Bill Stephenson






On Feb 4, 2019, at 12:20 PM, Miles Fidelman  wrote:

Hi Folks,

I wonder if anybody has built a replicated blog engine on top of CouchDB - 
something like WordPress that can run as multiple, synchronized, local copies.

Anybody know of such a beast?

Thanks very much,

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra



--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: replicated blog engine?

[Miles Fidelman]

And that will replicate to other couchdb instances hosting the page?

Miles

On 2/4/19 3:47 PM, Bill Stephenson wrote:

Yes, viewer comments are added to the blog post doc with a perl script running 
on the server side.

I’d be glad to send you the script.

Kindest Regards,

Bill Stephenson
Tech Support
www.cherrypc.com <http://www.ezinvoice.com/>
1-417-546-8390





On Feb 4, 2019, at 2:41 PM, Miles Fidelman  wrote:

Martin & Bill - thanks for your replies & pointers!  Both look interesting.

Bill - a follow-up:  Does the single page blog, at azartiz.com, support replication 
of comments?  My goal is to publish a blog, distribute it to various social media 
sites, and build a single discussion community around each post.  I prefer to take 
a replicated approach for the database, on general principles (reliability and 
such).  Essentially, publish via RSS, with each post & associated comments 
becoming their own mesh network.

Thanks Again,

Miles

On 2/4/19 1:24 PM, Bill Stephenson wrote:

I’m not sure if it qualifies, but you’re welcome to take a look the blog I've 
made at azartiz.com.

Kindest Regards,

Bill Stephenson






On Feb 4, 2019, at 12:20 PM, Miles Fidelman  wrote:

Hi Folks,

I wonder if anybody has built a replicated blog engine on top of CouchDB - 
something like WordPress that can run as multiple, synchronized, local copies.

Anybody know of such a beast?

Thanks very much,

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra



--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: replicated blog engine?

[Miles Fidelman]

Martin & Bill - thanks for your replies & pointers!  Both look interesting.

Bill - a follow-up:  Does the single page blog, at azartiz.com, support 
replication of comments?  My goal is to publish a blog, distribute it to 
various social media sites, and build a single discussion community 
around each post.  I prefer to take a replicated approach for the 
database, on general principles (reliability and such).  Essentially, 
publish via RSS, with each post & associated comments becoming their own 
mesh network.


Thanks Again,

Miles

On 2/4/19 1:24 PM, Bill Stephenson wrote:

I’m not sure if it qualifies, but you’re welcome to take a look the blog I've 
made at azartiz.com.

Kindest Regards,

Bill Stephenson






On Feb 4, 2019, at 12:20 PM, Miles Fidelman  wrote:

Hi Folks,

I wonder if anybody has built a replicated blog engine on top of CouchDB - 
something like WordPress that can run as multiple, synchronized, local copies.

Anybody know of such a beast?

Thanks very much,

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra



--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

replicated blog engine?

[Miles Fidelman]

Hi Folks,

I wonder if anybody has built a replicated blog engine on top of CouchDB 
- something like WordPress that can run as multiple, synchronized, local 
copies.


Anybody know of such a beast?

Thanks very much,

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: the future of couchapp

[Miles Fidelman]

Speaking as someone who writes proposals for a living, what I find 
confusing are terms that sound very clear - such as retire CouchApps - 
that require digging through lots of distributed materials to find 
clarification of what you really mean.


I.e., it's not CouchApps that are confusing - it's the verbiage that's 
confusing.


Personally, I'd like to see more language like:

CouchDB includes application server functionality, that supports both 
client-side and server side native applications, which we call CouchApps.

or maybe,
CouchApps are CouchDB's equivalent of Java applets and servelets.

I think those are pretty clear descriptions of CouchApps, at a 
conceptual level.  (If not, then maybe CouchApps really are confusing.)


Miles Fidelman



Jan Lehnardt wrote:

Funny how this proves my point about CouchApps being confusing. We can't even 
talk about their future without talking past each other.

In addition, cherry-picking quotes from my emails won't help to clarify things. I 
understand you *can* read a position of let's remove CouchApps into what I 
wrote, by only if you selectively ignore some of the things I also said. I don't think 
that is useful.

Please join marketing@ to join the uncut discussion there.

Best
Jan
--

Best
Jan
--

On 07.05.2015, at 15:10, Harald Kisch haraldki...@gmail.com wrote:

Sorry Jan, please don't take it personally but in your both emails you
definitely claimed out, that couchapps does'nt fit in YOUR CouchDB-Story.

In

http://markmail.org/message/no3jfksdxjcgxz4d

you personally said:
Technically, that would have meant CouchApps had to grow a lot more and I
realised quickly that CouchDB is not the right place to grow such a thing.

Sorry but for me it means you don't want CouchDB to have an App-Engine
inside. The only confusion is: What could be the issue for that? Every
database vendor works for decades on it? And why peer-to-peer should be
bad? Think on Git, torrent network, etc. pp. are these projects not the
leading inventions of the last decades based on peer-to-peer? And yes,
CouchDB is NOW extremely powerful with Apps executed out of its database
core and replicated anywhere without the need of permanent internet
connection!

Also in

http://markmail.org/message/xla3hulea4lo5duw

you personally said:
figure out a plan to retire “CouchApp”

Sorry this words are not misunderstandable for me. And I am wondering why
and how you can say that. And if you really want to retire CouchApp
because of confusions (for me it is the other way around - the storage is
part of the App-Engine because stupid containers you can find everywhere
based on node.js etc. to support the same as CouchDB's native App
Core-Feature called Couchapp)

CouchApps for me are the CouchDB Story. There is no confusion about that.
Please do not claim that somone has something against you and please take
it objective not emotional. But if you take such desruptive things into the
community, you should also stand for it to explain them accordingly and not
start to change the basics to loose all the current users of that
game-changing core-feature.

Best
Harald


On Thu, May 7, 2015 at 1:14 PM, Jan Lehnardt j...@apache.org wrote:

I never said CouchApps should be removed. Can everybody please stop
refuting a point that I never made. And lay off the personal attacks while
you are at it.

Best
Jan
--


On 07.05.2015, at 11:16, Harald Kisch haraldki...@gmail.com wrote:

Sorry guys, my eyes dont believe what they see..
@Jan: How are you? long time not spoken to eachother. How is Lena? What

she

is thinking about couchapps?

Why not to make a list of pros and cons for couchapps?
Did you ask jchris about removing couchapps?
Or why you don't directly ask Damien aboout the cause he implements it?

What is your benefit removing it?

For my part I have been successfully using it since 2008 and this is my
favorite use case for building secure, anywhere applications for the
industry and I would apreciate improvements on couchapps regarding
Authentication, LDAP and Active Directory erlang modules like built in

2010

and never improved.

We should not forget what CouchDB is all about. And for me the guys who
claim out to remove couchapp simply forget the power Damien have built in
and the power who made CouchDB proud to kick-off the no-sql area.
Dont forget who Damien really is. He is one of the leading developers of
Domino Notes aka Lotus Notes aka IBM Notes, registering 3 patents in USA
for it. Because only older guys know it, Lotus Notes was the previously
business standard groupware software for large scale companies before SAP
was destroying it's reputations with the help of IBM (which wanted only

to

sell their DB2 Database). Everybody who was working with Lotus Notes

begun

to love it. Not so SAP-Users, they are hating their daily work with SAP
because it simply don't work (complexity).

Couchapp is not complex and still have the power lotus notes has.

Remember:

Damien has built CouchDB because

Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)

[Miles Fidelman]

Jan Lehnardt wrote:

On 06 May 2015, at 17:57, Giovanni Lenzig.le...@smileupps.com  wrote:

Given the importance of the topic: the future of couchapp... I'm moving
this from the @marketing to the user@ mailing list.

I’d say this is too early, would prefer we keep this on marketing@ until
we have the messaging right. Everything else follows from them. Given that
user@ is missing the entire “the why of CouchDB” context that marketing@
has, I’d say moving this is premature.

I also *could* see this as a cheap ploy to quickly garner public pressure
against my position, but in good faith, I won’t assume this is your motive.


If this is the kind of discussion going on, on the marketing list, then 
you REALLY need to open it up to user feedback.  I think you're going 
off track.


Re. a couple of things below:

This should be definitely something @users should be involved in.. at least
those interested in Couchapps.

To recap:
Jan: wants to remove Couchapp name and design doc functions because it
finds them to be source of confusion

This does not adequately reflects my position. I don’t suggest to remove
any of the things that make CouchApps possible.

My larger argument can be foundhttp://markmail.org/message/no3jfksdxjcgxz4d  
andhttp://markmail.org/message/xla3hulea4lo5duw

tl;dr: I’d like us to think about how the CouchApp (or whatever the
final name might be) story fits into the larger CouchDB story of “Data where
you need it.” — Not necessarily how the slogan made be “true” in the context
of CouchApps (e.g. “Data (and logic) where you need it.”, but more:

- CouchDB’s core feature is geographically distributed replication.


Really?  That's the argument that lead to CouchBase.

Yes, MVCC w/ replication is A core feature, but, at least to me, Couch's 
core feature is a full-featured HTTP interface -- everything is a 
resource, accessed through RESTful HTTP operations.




- We also have somewhat quirky, while technically neat, applications that can
live inside CouchDB.

I don’t think that last bit helps paint the big picture CouchDB story at all.
Granted, I’m making a deliberately weak attempt of tying things together
(because I don’t know any better), but this is to get you thinking about how
this could fit in our larger narrative, if at all.


From this user's perspective, you're 100% wrong on this.  The fact that 
you can use CouchDB as an App Server is of particularly high value; the 
more so that the Apps can run in a browser.  More to the point - it's an 
HTML5 WebApp server, making it a full platform for RESTful applications.



My current thinking is that we can’t make it clear and thus should figure out a
plan to retire “CouchApp”, while still allowing all the cool tech, and find a
new name for the concept that can live on without making CouchDB’s core message
unclear.



Hell no!

Maybe the tooling for CouchApps is a bit funky, but the support for them 
is (IMHO) core features of Couch.  And the notion of Couch as an App 
Server is pretty straightforward - and the term fits quite nicely.


Rather than retire the term, or relegate it to obsucrity - market it 
aggressively!  Perhaps to the the extent of changing the current tag 
line on couchdb.apache.org from A Database for the Web to A Database 
and Integrated App Server for the Web.



Please join us on the market...@couchdb.apache.org list for this discussion.


Done :-)

Miles Fidleman


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: [DISCUSS] Improved CouchDB logo / tagline / project name

[Miles Fidelman]

Which suggests that the new logo should keep the couch, but replace the 
man with a cute animal - in keeping with open source tradition. :-)


Cat, Koala, .. a few appropriate animals come to mind.

Cheers,

Miles Fidelman

Alexander Shorin wrote:

The Time to Relax is not only tagline, but also the goal to aim for.
If you are not relaxed with CouchDB, probably, you just doing
something wrong or should file an issue about (:
--
,,,^..^,,,


On Tue, Oct 28, 2014 at 6:26 PM, Eric B ebenza...@gmail.com wrote:

On Tue, Oct 28, 2014 at 11:03 AM, Joan Touzet woh...@apache.org wrote:


A minority of individuals suggested that it may be time to change
the logo, the tagline and even the project name for various reasons.
If we're considering any of these steps, now would be the time to
figure that out -- prior to the impending 2.0 beta and release.

I'd like to steer discussion towards these points and away from
the topic of logo acceptability -- it's become clear to me that
there is no further useful discussion possible on that topic.


As a fairly newcomer to CouchDB, I'd like to contribute by giving my
viewpoint and insight into the discussion to date.   To be clear, I am not
personally offended  by the logo.  But to be entirely fair (and hopefully
no one will take offense at this), I don't particularly care too much about
it either.  I don't make technical decisions based on graphics, but rather
what the product provides.

To that extent, I chose CouchDB due to its feature set, community, and
platform availability.  I wanted something that I could use in a
distributed manner without too much hassles.  CouchDB offered me a solution
for this.  The fact that the tag line was CouchDB and Relax really meant
nothing to me either.

Coming from a RDBMS background, already moving to NoSQL has its challenges
in design and approach.  Using CouchDB as a persistence engine (and not an
actual web-server) to a Java application means that it's HTTP API doesn't
really impact me either (all access is wrapped in a library).

So from my perspective, the tagline ...Relax... isn't really even
accurate.  If anything, CouchDB has less standard support in Java  (ie:
no Spring libraries, etc) and makes it less relaxing than something like
MongoDB which has a big Spring following.

If the goal is to rethink the name/logo/tagline, then perhaps a more
appropriate approach would be to target its feature set: (random examples
purely to illustrate my point): Easy NoSQL for the web or Distributed
NoSQL made simple or something more directed.

But the primary goal, I believe, is to first decide whether anything
_needs_ to be changed.  As others have already mentioned, something will
always offend someone somewhere, in some different language or culture.
That being said, the question should rather be if the product/community has
outgrown the tagline, and if so, what a new tagline/name should be.

Thanks,

Eric

Re: Seeking for professional training help with CouchDB

[Miles Fidelman]

Reminds me of the old joke:

TV repair person comes in, bangs on the side of the set, it starts 
working again, writes bill for $100.
Customer says, what, $100 for banging on the set? and asks for 
itemized bill.

Repairperson write itemized bill
$10 - banging on the set
$90 - knowing where to bang

Or, in this context:  You or I can learn what we need to be reading 
documentation, wikis, and blogs; and with a lot of experimenting - but 
that could end up taking a huge amount of time.  An expert can provide 
professional training that presents a subset of all information, in an 
effective order - to transfer maximum knowledge in less time (or should 
be able to).  One is trading $s for hours.


Miles Fidelman

Robert Newson wrote:

My answer was as serious as the question what does an expert knows
that is so important that can't be learned on
documentation, wikis and blogs?.

An expert or experienced practitioner is someone who has already done
the above, and more, allowing you to exchange one commodity (money)
for another (working design or code).

B.


On 12 November 2013 18:41, matt j. sorenson m...@sorensonbros.net wrote:

if there were no demand for knowledge from those who've already attained
it, applied it, refined and honed it, there'd be no market economy for us
knowledge workers, and we'd all be out of jobs.

/always looking for the secret turbo button

--
*matt j. sorenson*


On Tue, Nov 12, 2013 at 12:39 PM, Benoit Chesneau bchesn...@gmail.comwrote:


On Tue, Nov 12, 2013 at 7:32 PM, Giovanni P fiat...@gmail.com wrote:


what does an expert knows that is so important that can't be learned on
documentation, wikis and blogs?


An expert has a real practice.

- benoit



On Tue, Nov 12, 2013 at 3:55 PM, Simon Metson si...@cloudant.com

wrote:

thecouchfirm.com


On Friday, 8 November 2013 at 22:33, Naik, Purushottam wrote:


Please provide with details on companies/experts who can provide with

professional training with CouchDB development.

Thanks

Purushottam G Naik (PG),
Senior Director iSeries Software,
Bally Technologies,
245 Town Park Drive,
5th Floor, Suite 500,
Town Park-Ravine One,
Kennesaw, GA 30144.
Direct 702-584-8899
Cell 404-903-0819
Main 770-420-2388
Fax 770-420-9650
pn...@ballytech.commailto:pn...@ballytech.com







--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Serving Simple HTML page to Public IP from CouchDB

[Miles Fidelman]

I assume that CouchDB is doing NAME-based virtual hosting, which means 
it's doing its matching based on the URL in the HTTP header, not the IP 
address.


So, instead of
[vhosts]
couch:5984 = /test/_design/test/_rewrite

in your config file, you might want to try:

[vhosts]
184.75.155.16:5984 = /test/_design/test/_rewrite

And see what happens.

Now, if that's an IP address subject to change (say, if you're on a home 
router provided by a broadband supplier), you're going to have troubles 
every once in a while.


Re. your comment in another message:

Okay, sorry about this I'm a programmer but I don't know anything about 
networking. I just want to be sure there's no way to achieve the functionality 
I'm talking about without 1) getting a domain name or 2) setting an entry in 
the /etc/hosts file on the computer I want to use to access the page. Is that 
right?


Not to be (too) snarky, but if you're going to be programming stuff that 
presents a network interface, you might consider learning something 
about networking.


Miles Fidelman



Chris Sphinx wrote:

Sure, here is a secret gist with the relevant files:

https://gist.github.com/chrissphinx/a9e8411fa6efefa9572c

To state the problem again: I cannot access the webpage by hitting:

http://184.75.155.16:5984

It will simply return the JSON welcome message. However, if I (or anyone else I 
assume) were to create an entry in THEIR /etc/hosts file:

184.75.155.16   couch

And hit the url:

http://couch:5984

Then it works. That's great, but it's not what I want. I want the public IP to 
go directly to the index.html file no matter what computer is hitting it. The 
only way I've found to get this to occur is to put in [vhosts]:

184.75.155.16:5984

The public IP. This DOES work, but it breaks the entire database. You can't 
write nor can you retrieve any docs from the database. This makes sense to me 
because the database isn't at the IP anymore, just the webpage.

A sysadmin friend of mine told me that this is why you need a vhost set up, but now it's 
beginning to seem as if I actually want a reverse proxy which is 
functionality that is not provided by CouchDB? Or is serving a couch app to the public IP 
possible with only Couch running on the RPi? Thank you for the help so far, it is really 
appreciated.


On Mar 19, 2013, at 4:53 AM, Dave Cottlehuber d...@jsonified.com wrote:


Hi Chris,

Sorry to hear you are stuck on this! I remember being equally
mind-boggled a couple years back. It will click soon hopefully.

BTW It will help a great deal if you can put a minimal case together 
post it back to the list (or via a paste service gist friendpaste
etc). vhosts, your CNAME, the design doc including the rewriter rules,
and the specific error message in the logfile.

I have this setup at home but power's off and I don't have the config
handy, if I have a free spot today I'll whip an example up. So this is
from memory,

Ensure you've got:

[httpd]
bind_address = 0.0.0.0

[vhosts]
cname:5984 = /dbname/_design/ddoc_name/_rewrite

in your local.ini, replacing cname, dbname, ddoc_name as appropriate.

In your design document, your rewriter key should be something like this:

[
{from: /,to: /index.html},
{from: /*,to: /* }
]

And obviously there should be an attachment called index.html within the ddoc.

Check through http://docs.couchdb.org/en/latest/pretty_urls.html and
see if that helps you out. I'm pretty sure out of this thread we can
put a better example up!

Note that you could also set http port to 80 both in the vhost and in
local.ini under [httpd] section which would be even tidier.

A+
Dave
On 19 March 2013 09:32, Chris Sphinx chrissph...@gmail.com wrote:

I have a CouchDB running on a RPi behind a router. I've seen countless tutorials about 
pretty urls, but no matter what I do I just cannot get this to work for my 
public IP. All I want to do is be able to serve a boring webpage to anyone that hits

http://my.pub.lic.ip:5984

But the only way I was able to do this is by putting the public IP under vhosts 
in the local.ini file. Doing so breaks the database and I can't access it in 
any way until I remove the line from the local.ini file and restart it. Trying 
to get at any part of the database results in:

{error:not_found,reason:Document is missing attachment}

Sure, I can set up something like 127.0.0.1tabcouch to hook up to http://couch:5984 
on the RPi. I can even load it from another machine, but I have to set my /etc/hosts on 
whatever machine I want to use to include my.pub.lic.iptabcouch. What if I want to 
allow anyone to access the page without having to hack their /etc/hosts file? How am I 
supposed to set this up?

I get the feeling that the only way to do this is to run something like ngix in 
front of the database with a reverse proxy, but I'm already killing an ant with 
a sledgehammer and I feel that there is just something I am overlooking here. 
Can anybody tell me what I'm doing wrong? Or walk me through how

Re: Uninstalling CouchDB After Installing from Source

[Miles Fidelman]

Michael Bykov wrote:

2013/2/21 Lenin lening...@gmail.com


I have tried un installed couchdb which is installed from source, how to
uninstall please help me





Hi, Vladimir Ilyich!

sudo rm -rf /

will remove it completely, yes.



Haven't looked lately, but I assume that make uninstall and make 
distclean and then removing the source directory would do the job.




--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Filemaker to CouchDB

[Miles Fidelman]

Probably a little more complicated than that.

Filemaker is interesting in that, unlike SQL, it allows for repeating 
fields - so you have to worry about more than exporting tables, you have 
to worry about records that have some structure.


While it provides for export to a lot of formats, including CSV and 
Excel, if your database includes repeating fields, you need to figure 
out how to export into something that lets you maintain the structure of 
complicated records. You could, for example:
- export to a format that does support repeating fields (Filemaker seems 
to support export of repeating fields to XML), then do something to 
convert to json for use w/Couch
- Filemaker will expose data via a web service - so you could write 
something that sucks data out of Filemaker then puts it into Couch


There does seem to be a lot of information available if you Google 
Filemaker, export, repeating fields, JSON, XML, and so forth.


Filemaker also is sort of a programming environment - people write 
fairly fancy applications that can go well beyond what people do with 
Excel macros.  If you also want to export those, you're on your own.  
(Not that long ago I was faced with an application written in an 
obsolete version of Filemaker, old enough that it will no longer run on 
newer versions of Mac OS.  Converting to something else was a right 
royal pain.)


Miles Fidelman

Mark Hahn wrote:

CSV?


On Wed, Feb 20, 2013 at 1:34 PM, Stephan Bardubitzki 
step...@bardubitzki.com wrote:


I don't even exactly know what Filemaker (seems to be not SQL based) is
about, however, it is heavily used in some government departments.

So, I just through out this question in case someone has done that before:

Is there any feasible procedure to convert/transfer data from Filemaker to
CouchDB?

Thanks in advance.

Stephan







--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Changes, CouchDB Conf Berlin The State of CouchDB

[Miles Fidelman]

This is all very good news.  Thanks Jan!

On 1 February 2013 22:05, Jan Lehnardt j...@apache.org wrote:

Hi Everybody!

I sat down and wrote up a few things that were going on recently that I’d
like to share with you:


Changes and New Beginnings

 http://writing.jan.io/2013/02/01/changes-and-new-beginnings.html


CouchDB Conf Recap

 http://writing.jan.io/2013/02/01/couchdb-conf-berlin-recap.html


The State of CouchDB (from CouchDB Conf):

 http://writing.jan.io/2013/02/01/the-state-of-couchdb.html






--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: serious problems w/ new install - SOLVED

[Miles Fidelman]

Original problem:  Installed Erlang 15-latest and Couch 1.2.1 from 
source, on Debian Stable (Squeeze), but developer tests all failed.


Original diagnosis (help from list): Needed to install a later SeaMonkey 
than in the Debian package repo - repo is 1.9, poster to this list 
indicated 1.8.5 was needed.  TURNS OUT THIS IS NOT THE CASE.


After a lot of dependency hell, including building Erlang from source 
and working through some dependency issues re. wxwidgets, it turns out 
that the problem is with with the INSTRUCTIONS:


- Where CouchDB 1.2.1 is concerned, the instructions in the tarball 
(INSTALL.Unix) work perfectly on Debian Squeeze.  (Note: this is with 
the less-than-latest, packaged, Erlang release).


but... if one follows the directions on couchdb.apache.org:

1. They're hard to find:
- couch.apache.org - quicklinks - wiki.apache.org/couchdb/ - 
wiki.apache.org/couchdb/Installation
- that file is out of date - it explicitly calls out rels. 1.0 and 1.1 
(only), and, in it's distribution-specific instructions conspicuously 
leaves out Debian
- it has a link 
https://git-wip-us.apache.org/repos/asf/couchdb/repo?p=couchdb.git;a=blob;f=INSTALL.Unix;hb=master 
https://git-wip-us.apache.org/repos/asf/couchdb/repo?p=couchdb.git;a=blob;f=INSTALL.Unix;hb=master,- 
which would seem to be the latest version, but which, in turn,
- includes the line: For up to date instructions, please see: 
http://wiki.apache.org/couchdb/Installing_on_Debian;
- note: INSTALL.Unix in git (the above link) differ significantly than 
what's in the 1.2.1 tarball - specifically in the list of packages to 
install from the Debian repo.


2. I made the mistake of following the Installing on Debian 
instructions on the web site, which turn out to be rather badly wrong:
- they describe how to install a later, but not the latest, version of 
Erlang (R15B01, latest is R15B03-1, Debian stable package is R14A)
- the Erlang instructions say to omit js, jinterface, odbc, wx - which 
kind of defeats the purpose of building a full Erlang from source
--- note: I went down a rathole building the latest wxwidgets from 
source - it puts one of its header files in a place that the Erlang 
build scripts
  don't look - took a while to figure that out, but that's 
not relevant here.  And, it turns out that a sufficiently recent version of

  wxwidgets is already in the Debian package repo.
- the instructions give a ./configure line that points the build process 
to the wrong place viz-a-viz mozjs
-- I'm pretty sure that last is what messes up the developer tests, and 
led the the suggestion of installing SpiderMonkey 1.8.5


Summary:
- the instructions in the tarball are correct, and work perfectly
- there are way to many OTHER versions of the instructions lying around, 
that are badly broken



Randall Leeds wrote:

From https://developer.mozilla.org/en-US/docs/SpiderMonkey:

SpiderMonkey 1.8.5 is the most recent standalone source code release.
  It implements JavaScript 1.8.5, and it is largely the same engine
that shipped with Firefox 4. You can download full source code here:
http://ftp.mozilla.org/pub/mozilla.org/js/js185-1.0.0.tar.gz (MD5
checksum: a4574365938222adca0a6bd33329cb32).


Unfortunately, the Mozilla folks decided to call the *library*
mozjs1.8.5, with 1.8.5 matching the JavaScript version. Notice how it
ends with -1.0.0. Unfortunately, a change that came quickly after that
broke compatibility with CouchDB and we have not yet sorted what to do
about that. For this reason, it's important to install
libmozjs185-1.0.0 or some equivalent package of a different name.
Unstable repositories for debian are shipping new ones which will not
work, although Mozilla has not made any further official releases.

On Fri, Jan 11, 2013 at 10:01 AM, Miles Fidelman
mfidel...@meetinghouse.net wrote:

Well yes, but... it's seeming just a bit hard to track down.  There seem to
be lots of different libraries that start w/ libmozjs (libmozjs2
libmozjs185, ...) and upstream for later versions seems to be iceweasil.

So a pointer to an appropriate source would be really helpful.

And then I expect that this needs to be a little different:


./configure --prefix=/usr/local --with-js-lib=/usr/lib
--with-js-include=/usr/**include/mozjs --enable-init



Octavian Damiean wrote:

Hello there,

If that package doesn't exist you should build it yourself.


On Fri, Jan 11, 2013 at 6:36 PM, Miles Fidelman
mfidel...@meetinghouse.netwrote:


Well that's kind of bothersome, in several regards:

1. the official install instructions are wrong

the INSTALL.Unix file specifies libmozjs-dev

as does

http://wiki.apache.org/**couchdb/Installing_on_Debianhttp://wiki.apache.org/couchdb/Installing_on_Debian
which also calls for libmozjs2d

neither calls for libmozjs185-dev

2. libmozjs185-dev is not available for Debian stable (Squeeze) - just
for
testing and sid

Seems generally problematic.

Any workarounds you can suggest?




Robert Newson wrote

Re: serious problems w/ new install - SOLVED

[Miles Fidelman]

Dave Cottlehuber wrote:

Hi Miles,

Thanks for this weighty investigation.


De nada. Had to get the system up. :-)


The wiki pages were being updated for 1.3.x but it looks like we'll
need a separate section for each release of debian/ubuntu.


Unfortunately, probably for each combination of:
{CouchDB Release}{Erlang Release}{Debian/Ubuntu Release}

Though it can be simplified just a bit by not describing source builds 
of Erlang and SpiderMonkey for the cases where the packages are 
sufficient.  I.e.,


CouchDB-latest on Debian Stable, Wheezy, Sid, Ubuntu equivalents (at 
least through 1.2.1 CouchDB builds on the Debian Stable packages, per 
the instructions in the Tarball


If you want, I can contribute instructions for 1.2.1 on the latest Erlang.

Miles

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

wiki based on couchdb?

[Miles Fidelman]

Hi Folks,

Anybody know of a wiki, based on couchdb, that's made it to rel. 1? 
(Pages and TapirWiki both seem immature, and nobody has touched their 
code in a couple of years.  Is there anything out there that's a bit 
more mature?)


Thanks!

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

custom conflict handlers?

[Miles Fidelman]

I'm trying to understand alternatives for handling update conflicts.  Is 
there direct way to detect a conflict between two updates to the same 
document, and trigger a custom handler (as opposed to letting Couch's 
basic conflict resolution algorithm proceed, then undoing things 
after-the-fact)?


Context:  I'm trying to replicate the behavior of version control 
systems - i.e., on conflict, create a branch (two documents).


Thanks,

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

serious problems w/ new install

[Miles Fidelman]

Hi Folks,

HELP!

Just installed CouchDB 1.2.1 under Debian (Squeeze, amd64), using the 
instructions at

http://wiki.apache.org/couchdb/Installing_on_Debian

Notice a few things during the install:
- make test ran all but one test successfully - 220-compaction-daemon.t 
Failed
- make did NOT install the startup script in /etc/init.d/ - had to copy 
it in manually
- it seems sort of odd for Couch to install config stuff under 
/usr/local/etc, rather than /etc (non-standard to say the least)

- everything starts up fine
- verify installation tells me everything is fine

but
- when I run the test suites, 39 of 62 fail!
- I'd love to share the test report, or a link to it (I told Futon to 
share it), but...
--- any suggestions on how either extract the local copy in a form that 
can be attached to an email, or,
--- how to identify the report in the 7000 or so in the shared test 
report database?


First question: any simple way to extract the test report as a document 
I can attach to an email


HELP!!!

Thanks,

Miles Fidelman




--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: serious problems w/ new install

[Miles Fidelman]

Robert Newson wrote:

The install root defaults to /usr/local/ so installing config stuff to
/etc instead of /usr/local/etc would be non-standard (to say the
least).


Fair enough.



What version of SpiderMonkey do you have installed?


The directions I followed were based on using mozjs, with directions to  
install libmozjs-dev libmozjs2d via apt, and to configure w/


./configure --prefix=/usr/local --with-js-lib=/usr/lib 
--with-js-include=/usr/include/mozjs --enable-init

looks like version 1.9.1.16-20 of both packages (the current one from 
the Debian Squeeze repo.)





B.

On 11 January 2013 16:43, Miles Fidelman mfidel...@meetinghouse.net wrote:

Hi Folks,

HELP!

Just installed CouchDB 1.2.1 under Debian (Squeeze, amd64), using the
instructions at
http://wiki.apache.org/couchdb/Installing_on_Debian

Notice a few things during the install:
- make test ran all but one test successfully - 220-compaction-daemon.t
Failed
- make did NOT install the startup script in /etc/init.d/ - had to copy it
in manually
- it seems sort of odd for Couch to install config stuff under
/usr/local/etc, rather than /etc (non-standard to say the least)
- everything starts up fine
- verify installation tells me everything is fine

but
- when I run the test suites, 39 of 62 fail!
- I'd love to share the test report, or a link to it (I told Futon to share
it), but...
--- any suggestions on how either extract the local copy in a form that can
be attached to an email, or,
--- how to identify the report in the 7000 or so in the shared test report
database?

First question: any simple way to extract the test report as a document I
can attach to an email

HELP!!!

Thanks,

Miles Fidelman




--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra




--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: serious problems w/ new install

[Miles Fidelman]

Well that's kind of bothersome, in several regards:

1. the official install instructions are wrong

the INSTALL.Unix file specifies libmozjs-dev

as does
http://wiki.apache.org/couchdb/Installing_on_Debian
which also calls for libmozjs2d

neither calls for libmozjs185-dev

2. libmozjs185-dev is not available for Debian stable (Squeeze) - just 
for testing and sid


Seems generally problematic.

Any workarounds you can suggest?



Robert Newson wrote:

Ah, that would be at least part of the problem, you need 1.8.5.
libmozjs185-dev, iirc.

B.

On 11 January 2013 17:05, Miles Fidelman mfidel...@meetinghouse.net wrote:

Robert Newson wrote:

The install root defaults to /usr/local/ so installing config stuff to
/etc instead of /usr/local/etc would be non-standard (to say the
least).


Fair enough.



What version of SpiderMonkey do you have installed?


The directions I followed were based on using mozjs, with directions to
install libmozjs-dev libmozjs2d via apt, and to configure w/

./configure --prefix=/usr/local --with-js-lib=/usr/lib
--with-js-include=/usr/include/mozjs --enable-init

looks like version 1.9.1.16-20 of both packages (the current one from the
Debian Squeeze repo.)




B.

On 11 January 2013 16:43, Miles Fidelman mfidel...@meetinghouse.net
wrote:

Hi Folks,

HELP!

Just installed CouchDB 1.2.1 under Debian (Squeeze, amd64), using the
instructions at
http://wiki.apache.org/couchdb/Installing_on_Debian

Notice a few things during the install:
- make test ran all but one test successfully - 220-compaction-daemon.t
Failed
- make did NOT install the startup script in /etc/init.d/ - had to copy
it
in manually
- it seems sort of odd for Couch to install config stuff under
/usr/local/etc, rather than /etc (non-standard to say the least)
- everything starts up fine
- verify installation tells me everything is fine

but
- when I run the test suites, 39 of 62 fail!
- I'd love to share the test report, or a link to it (I told Futon to
share
it), but...
--- any suggestions on how either extract the local copy in a form that
can
be attached to an email, or,
--- how to identify the report in the 7000 or so in the shared test
report
database?

First question: any simple way to extract the test report as a document I
can attach to an email

HELP!!!

Thanks,

Miles Fidelman




--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra



--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra




--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: serious problems w/ new install

[Miles Fidelman]

Well yes, but... it's seeming just a bit hard to track down.  There seem 
to be lots of different libraries that start w/ libmozjs (libmozjs2 
libmozjs185, ...) and upstream for later versions seems to be iceweasil.


So a pointer to an appropriate source would be really helpful.

And then I expect that this needs to be a little different:

./configure --prefix=/usr/local --with-js-lib=/usr/lib 
--with-js-include=/usr/**include/mozjs --enable-init



Octavian Damiean wrote:

Hello there,

If that package doesn't exist you should build it yourself.


On Fri, Jan 11, 2013 at 6:36 PM, Miles Fidelman
mfidel...@meetinghouse.netwrote:


Well that's kind of bothersome, in several regards:

1. the official install instructions are wrong

the INSTALL.Unix file specifies libmozjs-dev

as does
http://wiki.apache.org/**couchdb/Installing_on_Debianhttp://wiki.apache.org/couchdb/Installing_on_Debian
which also calls for libmozjs2d

neither calls for libmozjs185-dev

2. libmozjs185-dev is not available for Debian stable (Squeeze) - just for
testing and sid

Seems generally problematic.

Any workarounds you can suggest?




Robert Newson wrote:


Ah, that would be at least part of the problem, you need 1.8.5.
libmozjs185-dev, iirc.

B.

On 11 January 2013 17:05, Miles Fidelman mfidel...@meetinghouse.net
wrote:


Robert Newson wrote:


The install root defaults to /usr/local/ so installing config stuff to
/etc instead of /usr/local/etc would be non-standard (to say the
least).


Fair enough.


  What version of SpiderMonkey do you have installed?
The directions I followed were based on using mozjs, with directions to
install libmozjs-dev libmozjs2d via apt, and to configure w/

./configure --prefix=/usr/local --with-js-lib=/usr/lib
--with-js-include=/usr/**include/mozjs --enable-init

looks like version 1.9.1.16-20 of both packages (the current one from the
Debian Squeeze repo.)



  B.

On 11 January 2013 16:43, Miles Fidelman mfidel...@meetinghouse.net
wrote:


Hi Folks,

HELP!

Just installed CouchDB 1.2.1 under Debian (Squeeze, amd64), using the
instructions at
http://wiki.apache.org/**couchdb/Installing_on_Debianhttp://wiki.apache.org/couchdb/Installing_on_Debian

Notice a few things during the install:
- make test ran all but one test successfully - 220-compaction-daemon.t
Failed
- make did NOT install the startup script in /etc/init.d/ - had to copy
it
in manually
- it seems sort of odd for Couch to install config stuff under
/usr/local/etc, rather than /etc (non-standard to say the least)
- everything starts up fine
- verify installation tells me everything is fine

but
- when I run the test suites, 39 of 62 fail!
- I'd love to share the test report, or a link to it (I told Futon to
share
it), but...
--- any suggestions on how either extract the local copy in a form that
can
be attached to an email, or,
--- how to identify the report in the 7000 or so in the shared test
report
database?

First question: any simple way to extract the test report as a
document I
can attach to an email

HELP!!!

Thanks,

Miles Fidelman




--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra



--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra



--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra





--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: serious problems w/ new install

[Miles Fidelman]

Of course one might also wonder why all but one make test tests work 
just fine, but the ones run through futon don't.


Robert Newson wrote:

Those instructions date to when those packages were compatible, agree
it should be updated now.



On 11 January 2013 17:37, Octavian Damiean odami...@linux.com wrote:

Hello there,

If that package doesn't exist you should build it yourself.


On Fri, Jan 11, 2013 at 6:36 PM, Miles Fidelman
mfidel...@meetinghouse.netwrote:


Well that's kind of bothersome, in several regards:

1. the official install instructions are wrong

the INSTALL.Unix file specifies libmozjs-dev

as does
http://wiki.apache.org/**couchdb/Installing_on_Debianhttp://wiki.apache.org/couchdb/Installing_on_Debian
which also calls for libmozjs2d

neither calls for libmozjs185-dev

2. libmozjs185-dev is not available for Debian stable (Squeeze) - just for
testing and sid

Seems generally problematic.

Any workarounds you can suggest?




Robert Newson wrote:


Ah, that would be at least part of the problem, you need 1.8.5.
libmozjs185-dev, iirc.

B.

On 11 January 2013 17:05, Miles Fidelman mfidel...@meetinghouse.net
wrote:


Robert Newson wrote:


The install root defaults to /usr/local/ so installing config stuff to
/etc instead of /usr/local/etc would be non-standard (to say the
least).


Fair enough.


  What version of SpiderMonkey do you have installed?
The directions I followed were based on using mozjs, with directions to
install libmozjs-dev libmozjs2d via apt, and to configure w/

./configure --prefix=/usr/local --with-js-lib=/usr/lib
--with-js-include=/usr/**include/mozjs --enable-init

looks like version 1.9.1.16-20 of both packages (the current one from the
Debian Squeeze repo.)



  B.

On 11 January 2013 16:43, Miles Fidelman mfidel...@meetinghouse.net
wrote:


Hi Folks,

HELP!

Just installed CouchDB 1.2.1 under Debian (Squeeze, amd64), using the
instructions at
http://wiki.apache.org/**couchdb/Installing_on_Debianhttp://wiki.apache.org/couchdb/Installing_on_Debian

Notice a few things during the install:
- make test ran all but one test successfully - 220-compaction-daemon.t
Failed
- make did NOT install the startup script in /etc/init.d/ - had to copy
it
in manually
- it seems sort of odd for Couch to install config stuff under
/usr/local/etc, rather than /etc (non-standard to say the least)
- everything starts up fine
- verify installation tells me everything is fine

but
- when I run the test suites, 39 of 62 fail!
- I'd love to share the test report, or a link to it (I told Futon to
share
it), but...
--- any suggestions on how either extract the local copy in a form that
can
be attached to an email, or,
--- how to identify the report in the 7000 or so in the shared test
report
database?

First question: any simple way to extract the test report as a
document I
can attach to an email

HELP!!!

Thanks,

Miles Fidelman




--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra



--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra



--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra





--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: serious problems w/ new install - mozjs185 doesn't help

[Miles Fidelman]

 JS_FS passed 5 arguments, but 
takes just 4

couch_js/sm180.c:274: error: initialization from incompatible pointer type
couch_js/sm180.c:284:63: error: macro JS_FS passed 5 arguments, but 
takes just 4

couch_js/sm180.c:284: error: missing braces around initializer
couch_js/sm180.c:284: error: (near initialization for 'global_functions[0]')
couch_js/sm180.c:284: error: initializer element is not constant
couch_js/sm180.c:284: error: (near initialization for 
'global_functions[0].name')
couch_js/sm180.c:285:55: error: macro JS_FS passed 5 arguments, but 
takes just 4

couch_js/sm180.c:285: error: initializer element is not constant
couch_js/sm180.c:285: error: (near initialization for 
'global_functions[0].call')
couch_js/sm180.c:286:61: error: macro JS_FS passed 5 arguments, but 
takes just 4

couch_js/sm180.c:286: error: initializer element is not constant
couch_js/sm180.c:286: error: (near initialization for 
'global_functions[0].nargs')
couch_js/sm180.c:287:59: error: macro JS_FS passed 5 arguments, but 
takes just 4

couch_js/sm180.c:287: error: initializer element is not constant
couch_js/sm180.c:287: error: (near initialization for 
'global_functions[0].flags')
couch_js/sm180.c:288:67: error: macro JS_FS passed 5 arguments, but 
takes just 4

couch_js/sm180.c:288: error: initializer element is not constant
couch_js/sm180.c:288: error: (near initialization for 
'global_functions[1].name')
couch_js/sm180.c:289:59: error: macro JS_FS passed 5 arguments, but 
takes just 4

couch_js/sm180.c:289: error: initializer element is not constant
couch_js/sm180.c:289: error: (near initialization for 
'global_functions[1].call')

couch_js/sm180.c:290: error: braces around scalar initializer
couch_js/sm180.c:290: error: (near initialization for 
'global_functions[1].nargs')
couch_js/sm180.c:290: error: initialization makes integer from pointer 
without a cast

couch_js/sm180.c:290: error: excess elements in scalar initializer
couch_js/sm180.c:290: error: (near initialization for 
'global_functions[1].nargs')

couch_js/sm180.c:290: error: excess elements in scalar initializer
couch_js/sm180.c:290: error: (near initialization for 
'global_functions[1].nargs')

couch_js/sm180.c:290: error: excess elements in scalar initializer
couch_js/sm180.c:290: error: (near initialization for 
'global_functions[1].nargs')

couch_js/sm180.c: In function 'main':
couch_js/sm180.c:301: error: 'JSScript' undeclared (first use in this 
function)
couch_js/sm180.c:301: error: (Each undeclared identifier is reported 
only once

couch_js/sm180.c:301: error: for each function it appears in.)
couch_js/sm180.c:301: error: 'script' undeclared (first use in this 
function)
couch_js/sm180.c:301: error: invalid operands to binary * (have 'struct 
JSFunctionSpec *' and 'struct JSFunctionSpec *')

couch_js/sm180.c:301: error: statement with no effect
couch_js/sm180.c:345: error: passing argument 5 of 'JS_InitClass' from 
incompatible pointer type
/usr/local/include/js/jsapi.h:2110: note: expected 'JSNative' but 
argument is of type 'JSBool (*)(struct JSContext *, struct JSObject *, 
uintN,  jsval *, jsval *)'
couch_js/sm180.c:359: error: assignment makes pointer from integer 
without a cast

couch_js/sm180.c:364: error: implicit declaration of function 'JS_AddRoot'
couch_js/sm180.c:370: error: statement with no effect
couch_js/sm180.c:376: error: passing argument 3 of 'JS_ExecuteScript' 
from incompatible pointer type
/usr/local/include/js/jsapi.h:2802: note: expected 'struct JSObject *' 
but argument is of type 'struct JSFunctionSpec *'
couch_js/sm180.c:379: error: implicit declaration of function 
'JS_RemoveRoot'

make[4]: *** [couchjs-main.o] Error 1
make[4]: Leaving directory 
`/usr/local/src/apache-couchdb-1.2.1/src/couchdb/priv'



Further suggestions?

Thanks,

Miles Fidelman



Robert Newson wrote:

Ah, that would be at least part of the problem, you need 1.8.5.
libmozjs185-dev, iirc.

B.

On 11 January 2013 17:05, Miles Fidelman mfidel...@meetinghouse.net wrote:

Robert Newson wrote:

The install root defaults to /usr/local/ so installing config stuff to
/etc instead of /usr/local/etc would be non-standard (to say the
least).


Fair enough.



What version of SpiderMonkey do you have installed?


The directions I followed were based on using mozjs, with directions to
install libmozjs-dev libmozjs2d via apt, and to configure w/

./configure --prefix=/usr/local --with-js-lib=/usr/lib
--with-js-include=/usr/include/mozjs --enable-init

looks like version 1.9.1.16-20 of both packages (the current one from the
Debian Squeeze repo.)




B.

On 11 January 2013 16:43, Miles Fidelman mfidel...@meetinghouse.net
wrote:

Hi Folks,

HELP!

Just installed CouchDB 1.2.1 under Debian (Squeeze, amd64), using the
instructions at
http://wiki.apache.org/couchdb/Installing_on_Debian

Notice a few things during the install:
- make test ran all but one test successfully - 220-compaction-daemon.t
Failed
- make did NOT install the startup script in /etc/init.d/ - had

Re: NEW LIST for learning Erlang and CouchDB

[Miles Fidelman]

Quite the contrary.  Lots of learning resources and a great community.  
Perhaps hard to grasp, in that functional programming and massive 
concurrency are non-traditional ways of approaching things.


goog cheng wrote:

I'm a newbie , it seems erl is hard to learn and lack an established
community  ...so ...

2012/10/18 Octavian Damiean mainer...@gmail.com


I'm pretty certain that this list or the new list is not about discussing
advantages or disadvantages of language X and Y. Especially not if the
question is so open-ended.

Cheers,
Octavian

On Thu, Oct 18, 2012 at 10:26 AM, goog cheng googch...@gmail.com wrote:


Erlang,python,c  which advantages does  each one  has

2012/10/17 Noah Slater nsla...@apache.org


Hey peeps,

Want to contribute, but don't know where to start, or don't know

Erlang?

I'm pleased to announce that we have a new list for learning Erlang and
CouchDB.

The idea here is to provide a friendly, like-minded environment for

people

who are interested in hacking on Couch to learn some Erlang.

Ask questions, get feedback, learn the codebase, and generally chitchat
with other CouchDB folk who are also learning Erlang. (As well as our

core

hackers who will be around to help you if you get stuck or need

guidance!)

Subscribe by sending an email to:

erlang-subscr...@couchdb.apache.org


(The mail archives will be up in a few hours.)

Thanks!

--
NS




--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Best stack for querying spatial locations

[Miles Fidelman]

On Tue, 5 Jun 2012 11:56:19 +0200 Luca Matteislmatt...@gmail.com  wrote:



  - what kinds of queries are going to be made against the data?

The idea is that the UI will be built using Google Maps. Some layers
are going to appear to let users filter the data. Like to layers for
countries and maybe other areas with specific climate information, so
that users can filter on that. The logic to define these layers I
expect is going to be on the client, so Couch doesn't need to worry
about that, it only needs to answer with the coordinates given a
specific area (which GeoCouch does perfectly already, right?).

Also simple queries like give me all the missions with these date
ranges. So Couch does this quite easily, all I need is to build a
view.



 - RESTful API implies a liklihood of combining the data with other  
data/services - so what kinds of things will people be doing? Yes 
indeed. One of the reasons I want to use Couch is because of its REST 
capabilities. We don't have any plans for now to make the data 
available to other services, but the idea that we can in the future is 
what gives us confidence to go ahead with Couch.




It all sounds fairly simple. The one comment I'd make is that you'd be 
well off looking around for tools and libraries that you're likely to 
use for mashing your data with Google Maps - e.g. libraries that munge 
data into KML to feed to Google Maps.  If a lot of the code you need is 
available for Couch, use Couch; if it's available for something else, 
use that.



When I hear geospatial stack I don't generally think MS Access and
  CouchDB. =A0I tend to think more:
  - Google Maps  KML, and/or
  - GeoServer + PostGIS, and/or
  - OpenLayers, and/or
  - ESRI ArcGIS (for really serious commercial capabilities)

Yes, We tried ArcGis in fact. But it's a very complicated piece of
software which is very hard to customize. It also appeared to be quite
slow with our ~2gb points. So we decided that a customized solution
might be best.


Well yes, ArcGIS is about the last thing to use if you can avoid it. 
It's expensive, and very hard to customize (that's what their VARs do 
for a living).  If you're managing huge geospatial datasets (property 
records, military stuff), or doing serious cartography, it's the best 
way to go.  Otherwise, to be avoided.  (Think Oracle vs. MySQL.  If 
you're a bank, you go with Oracle, otherwise MySQL or NoSQL.)




  Or, you might think about something more like:
  - MS Access -  GeoServer (w/ some RESTful glue) -  CouchDB -  user facing

What's a GeoServer? How is it different than CouchDB + GeoCouch?


Well, first off, it's a REAL spatial database. It's a geodata server 
built on top of PostGIS (PostgreSQL with geospatial extensions).  The 
key thing is that it supports both SQL and all of the standard 
geospatial interfaces (Open Geospatial Forums WMS and WFS, KML) and 
provides some RESTful interfaces as well. (WMS=Web Mapping Service, 
WFS=Web Feature Service - APIs for accessing geodata.  They're primarily 
SOAP style web services, but there are RESTful bindings as well.)




  Or it might make sense to keep some stuff in a geodatabase, other stuff in
  Couch, and mash stuff together in browser-side code.

What do you mean by geodatabase. Like ArcGIS?


Well, actually ArcGIS isn't a spatial database, as much as a set of 
tools (analytics, GUI, libraries) written on top of a spatial database 
(in their case Oracle Spatial).  What distinguishes a spatial database 
are additional fields and indices that make it easier to query along 
spatial dimensions - say to select all records within a bounding box.  
In general, these are implemented as extensions to SQL databases.  
GeoCouch is the equivalent for CouchDB.



Thanks for this, answering these questions made the situation a bit
clearer for me as well.

Let me know what you think would be the best way to go. I still think
that maybe going with CouchDB + GeoCouch would be the simplest
solution given the queries that we need to make against the system,
but there might be something else which is 100 times better.


Well... it doesn't seem like load, performance, or multi-user issues are 
going to be a problem, so it really comes down to how much code you're 
going to have to write  maintain, and maybe single-query performance.



Seems like your first choice is Architectural focusing on the UI.  As 
far as I can tell, it comes down to:


1. Google Maps - with a processing chain that looks like this:

Access - [data conversion  upload] - some-other-database - [query 
processing] - [KML generation] - Google Maps


implication: you're looking for the easiest way to generate KML, and the 
choice becomes one between


Access - [SQLtoJSON] - CouchDB - [Couch views that produce KML] - 
Google Maps

or
Access - [SQL dump] - GeoServer - [some pre-existing tool/library 
that produces KML] - Google Maps


2. A Mashup that draws from your API and Google's API:

Access - [data conversion  upload] - 

Re: Best stack for querying spatial locations

[Miles Fidelman]

Luca Matteis wrote:

Hello all,

I have a scenario where I'm working with a friend of mine that
maintains a bunch of spatial data in a MS Access database. I want to
put this data online, as a web-site, and allow people to query it
using an interface and a RESTful API. So I thought CouchDB + GeoCouch
would be perfect for this.

The issue is, how do I upload the MS Access data to my online Couch
instance? I want the process to be seamless - in the sense that my
friend will continue making modifications to his MS Access db, and
then he should upload it to the couch using some tool.

Do I need to write extra code to parse the MS Access into JSON and
then upload that to my couch? Or is there an easier way? Dunno, maybe
upload it the MS Access as an attachment and parse it with client side
JavaScript?

Also the MS Access is quite large: ~2gb



I think you've jumped a couple of design steps:
- what kinds of spatial data?
- is one person updating the data, or more?
- does the database live on a single PC, or on a server?
- how frequently is it updated?
- is it preferable for updates to propagate live to the online serve, or 
is a periodic dump enough (or preferred)?

- what kinds of queries are going to be made against the data?
- how many queries per unit of time?
- RESTful API implies a liklihood of combining the data with other 
data/services - so what kinds of things will people be doing?


When I hear geospatial stack I don't generally think MS Access and 
CouchDB.  I tend to think more:

- Google Maps  KML, and/or
- GeoServer + PostGIS, and/or
- OpenLayers, and/or
- ESRI ArcGIS (for really serious commercial capabilities)

Depending on the details of the problem at hand (the answers to the 
above questions), it could be that:
- MS Access - some glue - CouchDB/GeoCouch might be a perfectly good 
solution


Or, you might think about something more like:
- MS Access - GeoServer (w/ some RESTful glue) - CouchDB - user 
facing i/f


Or it might make sense to keep some stuff in a geodatabase, other stuff 
in Couch, and mash stuff together in browser-side code.


Your problem statement is way too amorphous at this point.

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Attachments and WebDev

[Miles Fidelman]

Benoit Chesneau wrote:

On Tue, Apr 24, 2012 at 6:48 PM, Benoit Chesneaubchesn...@gmail.com  wrote:

On Tue, Apr 24, 2012 at 3:39 PM, Henri van den Bulk
hvandenb...@gmail.com  wrote:

I have a need to use attachments with CouchDB and have them accessible via 
WebDev. Has anyone done this before?

WebDav or WebDV the software from PC Soft ?

i mean WebDev
Umm.  WebDev is a CASE tool.  WebDav is distributed authoring and 
versioning over http - which allows for, among other things, mounting 
files on a web server onto a PC, Mac, or Linux desktop.


If you really mean WebDev - what's your use case?

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Help shape the future of CouchDB: your voice needed!

[Miles Fidelman]

Bob Dionne wrote:

Mike,

I'd be interested in your thoughts on this. Damien presented the UnQL stuff to 
us, some time ago before he left the CouchDB project, and I thought then it was 
overly ambitious.

I agree that SQL is awesome and hard to get away from after thinking in terms 
of relations for years. I'd love to see an alternative to SQL that was a better 
fit for document stores, that takes into account that document are sorts of 
like objects with attributes. There was considerable work done in this area 
years ago by folks working in  functional dbs.

Umm CQL (Contextual Query Language, formerly known as Common Query 
Language).  Developed by the library community for querying metadata.


SRU (Search/Retrieve via URL) embeds CQL in a RESTful API.  Sort of 
OpenSearch on steroids.  Some mature implementations floating around.


Working example of a search string:
http://alcme.oclc.org/srw/search/SiteSearchDocumentation?query=dc.title= 
pearsversion=1.1maximumRecords=10 
http://alcme.oclc.org/srw/search/SiteSearchDocumentation?query=dc.title=%20pearsversion=1.1maximumRecords=10


Now an SRU interface to CouchDB would be interesting.

(Amazing how people always want to re-invent things rather than do a 
little research.)


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Why are reads from CouchDB so slow? (1.5MB/s or thereabouts)

[Miles Fidelman]

Jonathan Williamson wrote:

Also the result of:

time curl http://localhost:5984/  /dev/null
real0m0.011s
user0m0.000s
sys 0m0.000s

Suggests the overhead to be around 0.01 seconds.

Whereas to fetch a single document (700k in size):

time curl http://localhost:5984/[dbname]/[documentid]  /dev/null
real0m0.296s
user0m0.010s
sys 0m0.010s



Since you're measuring the end-to-end time of a client-server 
transaction, there are two additional components to the real-time number:

- time consumed while other things are happening
- time that is actually consumed by  processing your request

Pretty clearly, both those numbers are tiny for the baseline 
transaction, but for the CouchDB transaction, how much of what's taking 
up elapsed time is actual processing by CouchDB, and how much of the 
time is CouchDB waiting for something else to happen?


Is there a way to profile what CouchDB does once it receives that 
request? For that matter, what kind of profiling has been done of 
CouchDB's processing chain?


Miles Fidelman




--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: version control for documents?

[Miles Fidelman]

Simon Metson wrote:

Hi,
I can't think of a library off the top of my head. I think if I
were you I'd make a document containing editor and timestamp plus the
attachment for each version (with maybe some master document that
records metadata common to all versions which you could join).

If you want to have git like diffing then maybe just use git? ;)


Well... because we're looking to do things with the documents (e.g., 
search, semantic operations on the metadata) that are better done in Couch.


Now if git provided a RESTful API, that would be a different matter.  
(As far as I can tell, the only source control system to do so is the 
WebDAV interface provided by Subversion).  Now if anyone has integrated 
a git backend, with a CouchDB front-end, pointers would be much appreciated!


Miles


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

version control for documents?

[Miles Fidelman]

Hi Folks,

As part of a larger applicaiton, I'm looking at using CouchDB as a file 
cabinet to manage a collection of documents (surprise, surprise - it 
is a document database after all).  In this case, the documents really 
will be documents (e.g., a word document, or a file).  My simplistic 
model is that each Couch document will contain json-encoded metadata, 
and an attachment - the real document as a blob.


I want to apply version and change control to the documents and their 
metadata.  In essence, I want to do git-like stuff for text, html, and 
word documents.


I'm aware that CouchDB-style version control is not real version 
control a la git, cvs, or what have you - and I've seen some discussions 
on this list that suggest doing real version control has to be 
overlayed on Couch.


So... my question is:  Are there any good libraries and/or examples for 
doing so?


Thanks very much,

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

re:

[Miles Fidelman]

Gregor,

Somehow I missed your posting until just now, so first off.. thanks!

minutes.io looks very interesting - thanks for the info!

Miles


On 27 February 2012 12:17, Gregor Martynusgre...@martynus.net  wrote:


 Miles,

 I build minutes.io with a similar approach. You can use it when being offline, 
synchronization

with the couchApp backend is happening in the background.


 I don't think there is a library I'd recommend to use for such an 
architecture, not yet.

Maybe have a look at

 https://github.com/mikeal/browsercouch and https://github.com/mikeal/pouchdb

 I use backbone.js myself for the frontend and store all data in localStorage, 
which gets

synched asynchronously using _changes feed and _bulk_docs API. I also use a 
tiny node.js proxy
for security reasons and for some couchDB tasks like creating User Databases 
and Replications.


 I'm happy to answer any questions if you have any


On Thursday, 23. February 2012 at 03:10, Miles Fidelman wrote:



 I'm looking at building a data management application that's essentially
 a hybrid of an HTML5 WebApp (taking advantage of the App Cache and local
 data storage for disconnected operation) and a CouchApp (doing fancier
 stuff, data sharing, replication, etc. on one or more server-side
 CouchDB installations). If you think of a collection of linked
 spreadsheets - where each spreadsheet lives in CouchDB, but can be
 cached, viewed, and edited in-browser when disconnected - you won't be
 far off.

 My questions: Are there any good examples of applications that are
 already doing this kind of thing? Are there any good frameworks or
 libraries that I should be focusing on?


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Hybrid HTML5 WebApp / CouchApp - guidance sought

[Miles Fidelman]

Hi Folks,

I'm looking at building a data management application that's essentially 
a hybrid of an HTML5 WebApp (taking advantage of the App Cache and local 
data storage for disconnected operation) and a CouchApp (doing fancier 
stuff, data sharing, replication, etc. on one or more server-side 
CouchDB installations).  If you think of a collection of linked 
spreadsheets - where each spreadsheet lives in CouchDB, but can be 
cached, viewed, and edited in-browser when disconnected - you won't be 
far off.


My questions:  Are there any good examples of applications that are 
already doing this kind of thing?  Are there any good frameworks or 
libraries that I should be focusing on?


Thanks very much,

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Uninstalling CouchDB After Installing from Source

[Miles Fidelman]

Jonathan Porta wrote:

Hello,

Are there any guides to completely uninstalling CouchDB when it has been
installed from a compiled source?


perhaps:
./make uninstall
./make distclean

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Linux Alternatives for CouchDB

[Miles Fidelman]

Nestor Urquiza wrote:

If you decide to install in Ubuntu from sources give this a try:
http://thinkinginsoftware.blogspot.com/2011/10/installing-couchdb-in-ubuntu.html

I have installed it recently in 5 boxes following the guidelines
there. It installs BTW later candidate release (1.1.1)



Recently installed using these guidelines, on Debian:

from http://www.freshblurbs.com/install-couchdb-debian-squeeze-source



--
In theory, there is no difference between theory and practice.
Infnord  practice, there is.    Yogi Berra

Re: Comparison of MongoDB CouchDB: MongoDB seems better on insert

[Miles Fidelman]

Jan Lehnardt wrote:

Hi,

On 20 Dec 2010, at 22:32, Chenini, Mohamed wrote:

   

Hi,

I found this info on the net at 
http://www.slideshare.net/danglbl/schemaless-databases

 

I think the author's comment on slide 35 sums it up pretty nicely:

Of course this is just one (lame) test.

Coming up good numbers is hard which means that people with easy ways to make 
them come up with bad ones.
   
Let's see... 43 slides giving a pretty good overview of the history and 
state of noSQL databases (including several that are new to me), and all 
anybody has commented on was one slide on an avowedly lame benchmark.


Personally, I thought it was a very informative slide deck, of 
particular relevance to a project I'm working on.  Thanks for the 
pointer Mohamed.


Miles Fidelman

--
In theory, there is no difference between theory and practice.
Infnord  practice, there is.    Yogi Berra

Re: Document model of network

[Miles Fidelman]

Nils Breunese wrote:

I'm not familiar with neo4j, but it appears they have full support for 
transactions: http://wiki.neo4j.org/content/Transactions You'd have to talk to 
the neo4j people to learn more about this.
   
You might want to do a google search on graph database - there seem to 
be a number of new developments re. large-scale, distributed, RESTful 
beasts in that category.  In addition to neo4j, infogrid seems to pop up 
a lot (http://infogrid.org/).



--
In theory, there is no difference between theory and practice.
Infnord  practice, there is.    Yogi Berra

experience with very large numbers of nodes?

[Miles Fidelman]

Hi Folks,

Does anybody have any experience with very large Couch deployments - on 
the order of 100s to 1000s of nodes?


I'm looking at a peer-to-peer document management application, where 
every user has a copy of Couch on their desktop or a nearby LAN server.


I know that Couch's replication model purports to scale to very large 
numbers of nodes - but has anybody actually tried it, and lived to tell 
the tale?


Thanks,

Miles Fidelman

--
In theory, there is no difference between theory and practice.
Infnord  practice, there is.    Yogi Berra

reader_acl on Mac (Snow Leopard) - success

[Miles Fidelman]

Just installed the latest CouchDB under Snow Leopard.

Turns out the only straightforward way to get everything working is to 
do an install from Source:


- the one-click installer failed multiple tests

- installation from MacPorts failed the reader_acl test; and it wouldn't 
let me create an admin account (I expect this was the permissions 
problem someone reported)


- doing a clean install from Source, per the instructions at 
http://wiki.apache.org/couchdb/Installing_on_OSX went smoothly, and the 
resulting installation passed all the tests, including reader_acl, and 
let me create an admin account (NOTE: I made one change to the install 
instructions - they specified an earlier version of erlang_otp - I 
plugged in the latest ..14)


Miles Fidelman


--
In theory, there is no difference between theory and practice.
Infnord  practice, there is.    Yogi Berra

Re: Installing Couch on a machine with no internet and other issues

[Miles Fidelman]

On Mon, Jan 18, 2010 at 02:51:18PM -0500, Dave Ray wrote:

Hi. I'm in the situation where I'm going to be installing CouchDB on a
machine (RedHat Enterprise Linux)  with a couple limitations.

First, it has no internet access. I can bring software to it on CD or
DVD (after a thorough security process), but can't install anything
through a mechanism that requires internet access.
Second, it has very little installed on it, in particular no gcc, so
building from source would be difficult.
 
You could build CouchDB in a virtual machine image, than move that image 
to your stand-alone machine.


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

--
Miles R. Fidelman, Director of Government Programs
Traverse Technologies
145 Tremont Street, 3rd Floor
Boston, MA  02111
mfidel...@traversetechnologies.com
857-362-8314
www.traversetechnologies.com

Re: massive replication?

[Miles Fidelman]

Chris Anderson wrote:


If you do a hub-and-spoke or ring topology you can simplify the
replication problem a bit. But a gossip protocol is more resistant to
down nodes. I'd like to see a replication bus in the open source
project.

However, continuous replication will pretty much work.
  
The environment we're looking at is more of a mesh where connectivity is 
coming up and down - think mobile ad hoc networks.


I like the idea of a replication bus, perhaps using something like 
spread (http://www.spread.org/) or spines (www.spines.org) as a 
multi-cast fabric.


I'm thinking something like continuous replication - but where the 
updates are pushed to a multi-cast port rather than to a specific node, 
with each node subscribing to update feeds.


Anybody have any thoughts on how that would play with the current 
replication and conflict resolution schemes?


Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: massive replication?

[Miles Fidelman]

Paul,

I'm actually suggesting using NNTP infrastructure, or something like it, 
to propagate updates - rather than trying to reinvent the protocol and 
supporting infrastructure in CouchDB. 

Something like: 

change - local CouchDB instance -continuous replication (output) - 
local NNTP daemon (specific newsgroup) - the net


the net - local NNTP daemon (specific newsgroup) - continuous 
replication (input) - local CouchDB instance


All messages eventually get to all Couch instances - but the order and 
delay can vary considerably.


Miles


Paul Davis wrote:

Miles,

This sounds like what I was trying to propose. More concretely:

  

I keep coming back to NNTP (USENET) as a model for many-to-many messaging:

- push a message into a newsgroup on any NNTP node subscribing to that
newsgroup



A message group is persisted in a DB. In the future, a single db with
filtered replication could work, but a db per group will probably be
easier. Not all nodes have all db's.

  

- nodes exchange I-have/You-have on a regular basis



Replication of the network status db that holds what nodes have what
update_seq/host pairs. The pairing is important. The rate of
replication obviously affects delays and what not.

  

- message propagate to all subscribing nodes by essentially a flooding or
epidemic routing mechanism



This is the fun part. Given your local copy of a group, how do you
pick a peer to pull from. Or push to if you're feeling proactive. Do
we sync in both directions, etc etc. Depending on the behavior this
could manifest in multiple ways. If you have a single authority per
'subscription source' then you'd want to keep
authority/update_seq/located_at triples. This way you know that if
the largest update_seq seen is N, then you can replicate from any node
that has that sequence.

  

- pretty quickly, a message propagates to all nodes subscribing to the
newsgroup



Message delivery via replication. Judging the quickly part would
require a more formal definition of quickly and then building the
thing. Depending on your definition of quickly there are definitely
different types of design decisions to be made.

  

- lack of connectivity simply delays message propagation



Or reroutes through an alternate node. If we know that four nodes have
a copy of the db, we can replicate from any that are alive.
Replication is incremental, a link can disappear in the middle of a
replication and it'll resume from the previous check point.

  

- the whole system scales massively, and is very robust in the face of
connectivity outages, node failures, etc. (messages can flow across multiple
routes)



It scales on my brain debugger assuming the propagation algorithm
isn't extremely naïve. But as I said, I haven't built it yet so who
knows.

  

In some sense, what I'm thinking of would look a lot like:

- a group of CouchDB nodes all subscribe to a newsgroup



I'm confused by the term subscription here. Generally I'd assume that
means that a foreign host knows that the local node is interested in
something. For fully distributed awesome, I think it'd be better
phrased as nodes can declare what they want and the algorithm will
attempt to maintain their local state somewhere close to the global
state. Kind of like the difference between newspaper delivery and
buying a newspaper at any one of the many shops in town.

  

- each node publishes changes as messages to that newsgroup



$ curl -X PUT -d '{message: First post!!1!1}'
http://127.0.0.1:5984/newsgroup/memesrus

Part of the replication routing could include a proactive step in
pushing messages to nodes it  knows care about a message.

  

- NNTP takes care of getting messages everywhere, eventually



The 'network state in a db' means that regardless of who's interested
in what, if we make sure that the first step in node communication is
a 'i know about these endpoints in these states' then we'll push
information to the people that care. Eventually.

  

- each node looks for incoming messages and applies them as changes



Replication FTW!

  

- use a shared key to secure things (note: some implementations of NNTP
already support secure messaging)



This is slightly harder. Read only means you'd need something infront
of couch to prevent readers. But OAuth or distributing SSL certs or
similar wouldn't be out of the question.

  

A similar approach could be taken using:
- a distributed hash table as a message que (that's what spread and splines
seem to do)



I haven't looked to hard at these, but DHT as message queue seems
contradictory to the idea that most DHT's (all?) that I know of don't
allow range queries.

  

- the DIS or HLA protocols (used for distributed simulation - keeping
multiple copies of a world synchronized)



I couldn't get past the first wiki page Google gave me, so, I dunno.

HTH,
Paul Davis
  



--
In theory, there is no difference between theory and practice.
In practice, there 

massive replication?

[Miles Fidelman]

A couple of the recent CouchDB powerpoint presentations illustrate 
replication across massive numbers of database instances.  Does that 
represent anything remotely possible, for real? 

We have an application that involves replicating data across very large 
numbers of nodes that are intermittently connected - where we'd like 
collections of data to replicate and synchronize as connectivity 
allows.  Think something like USENET news as an analogy.


I'm trying to sort out whether or not CouchDB is a potential platform.

Thanks very much,

Miles Fidelman


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: massive replication?

[Miles Fidelman]

Daniel Trümper wrote:

Hi,

2. It seems like there's a point at which explicit 1-1 replication 
starts to be an administrative nightmare.  Some kind of 
publish-subscribe or multi-cast update model seems needed.
Would the new continuous replication feature be what you need? With 
this all changes to A get automatically replicated to B, if I get 
things right here...
Well it's more of, when I change A, I want the changes to propagate to B 
through Z (or all) - with some sort of multi-cast addressing rather 
than having to identify every node explicitly.


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Couchdb with OpenSSO

[Miles Fidelman]

Suhail Ahmed wrote:

Hi,

I am looking to replacing my existing content management engine with
couchdb. In order to do this properly, I would have to lock down the couchdb
REST interface using OpenSSO. I would be much obliged if anyone could point
out how I should go about it. There are a number of ways OpenSSO can be
integrated, RPC/REST, SOAP, Native Java API etc. In my current system, both
authentication and authorization is performed against OpenSSO (the reason
being that the system consists of more than just the content management
engine) centrally.
Where would I go about plugging in OpenSSO? Should I do it at the Erlang
layer? The couchdb layer or the mochiweb layer?
  
If you're running behind Apache, I'd suggest using one of the mod_auth 
modules, that's what they're for.



--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Replication and new user questions

[Miles Fidelman]

Blair Zajac wrote:

Hello,

We're looking at using CouchDB's replication to allow us to easily 
have multi-master replicating databases across multiple facilities, 
(e.g. Los Angeles, Albuquerque, Bristol, England, etc).  It looks like 
it'll be the perfect tool for the job.


Some questions on the current implementation and the work that I've 
read is going to be in forthcoming releases.


1) What's the most robust automatic replication mechanism?  While 
continuous replication looks nice, I see there's some tickets open 
with it and that it has issues with four nodes.  Is a more robust 
solution, but a little slower and heavier, it to have an 
update_notification that manually POSTs to _replicate?


2) With the persistent continuous replication feature, is there a way 
to stop continuous replication without restarting couchdb?  Will there 
be a way to manage the list of replicant databases when the persistent 
continuous replication feature is complete?


I'm sort of interested in this too.  We have an application we're 
developing that's somewhat analogous to USENET News.  What we want to do is:


1. define arbitrary groups, analogous to newsgroups

2. distribute control messages to a large number of nodes, allowing a 
node to subscribe (or not)


3. when a message (document) is posted (inserted) into a group, it gets 
replicated to all subscribed nodes


I keep looking at CouchDB and thinking this should be perfect for what 
we're doing, but the details of replication are really sketchy.


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra

Re: Replication and new user questions

[Miles Fidelman]

Adam Kocoloski wrote:

On Aug 25, 2009, at 5:17 PM, Miles Fidelman wrote:

I keep looking at CouchDB and thinking this should be perfect for 
what we're doing, but the details of replication are really sketchy.


Ouch :)  I'll try to get around to writing a solid wiki article on 
replication before the next release.  In the meantime check out


http://books.couchdb.org/relax/reference/replication


Did that yesterday :-)

Any idea when there'll be some documentation on change notification - 
which seems to be the other piece of the puzzle?


Thanks,

Miles

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra