Well, in my opinion it doesn't really matter if you send the ok or not, but
in the end I think the API should be consistent. Either you return ok on all
calls that don't retrun documents, or you use the HTTP status code on all.
Otherwise you make it more difficult for programmers to use it.
Best
RFC 2616 (HTTP/1.1) specifies the following classes [0]:
* 1xx Informational
* 2xx OK
* 3xx Redirection
* 4xx Client Error
* 5xx Server Error
So, if an operation was successful you should always get a 2xx.
Nils.
P.S. http://thoughtpad.net/alan-dean/http-headers-status.html has a great flow
Hi,
The only thing that CouchDB 'caches' is the open file handles and misc
Erlang PID's that need to be spawned to interact with a given view.
Depending on what state the server was in before your first request
that may have had a noticeable impact.
The second aspect is getting the FS caches hot
On 25 Oct 2009, at 23:58, Chris Anderson wrote:
On Sun, Oct 25, 2009 at 12:54 PM, Paul Davis
paul.joseph.da...@gmail.com wrote:
Hmmm. Now all we have to do is decide if we want ok:true or not.
Anyone have an opinion? It would remain more consistent with the
other
CRUD style operations
On 26 Oct 2009, at 09:06, Nils Breunese wrote:
Doesn't the HTTP status code already tell you whether the request
was successful or not? What does sending a bit of JSON add to that?
Browsers don't show response headers neither does curl (unless you
specifically ask them / tell them to).
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
On Oct 26, 2009, at 10:45 AM, Miles Fidelman wrote:
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,
Miles,
One the one hand, it sounds like you could solve this with XMPP and
use CouchDB as a backing store. People have already connected RabbitMQ
and CouchDB, I can't imagine that connecting ejabberd and CouchDB
would be much harder. The pubsub extensions could very much be what
you're wanting.
On Oct 26, 2009, at 11:35 AM, Chris Anderson wrote:
On Mon, Oct 26, 2009 at 8:33 AM, Miles Fidelman
mfidel...@meetinghouse.net wrote:
Adam Kocoloski wrote:
On Oct 26, 2009, at 10:45 AM, Miles Fidelman wrote:
The environment we're looking at is more of a mesh where
connectivity is
coming
After reading some Wikipedia it looks to me that Chris is right about an
information-spreading gossip protocol being the way to go. You could have
each node replicate with a small number of other nodes at random - or with
its neighbor nodes - some fixed number of times for minute. That should
On Oct 26, 2009, at 10:50 AM, Coffman, Timothy A wrote:
I am collecting information and doing some proofs-of-concept in
preparation for suggesting CouchDB as a replacement for a 20-year-old
house-developed document system. One topic I will need to address
goes
like this:
(1) How big can
Mark,
Python and Ruby both have good libraries available but as Couch speaks
HTTP it doesn't really require anything more than an HTTP client
library such as cURL.
Couch is language independent, just like a web server itself. You can
create new docs in couch using nothing more than an
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
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
Miles,
Oh. Gotchya. But the fun part is the protocol implementation ;)
Paul Davis
On Mon, Oct 26, 2009 at 2:21 PM, Miles Fidelman
mfidel...@meetinghouse.net wrote:
Paul,
I'm actually suggesting using NNTP infrastructure, or something like it, to
propagate updates - rather than trying to
Oh, sorry Adam, I wasn't told you're one of project developers/managers.
Thankyou for your reply.
Jan: yes, it could be another type of use. It's, we could say, load
balancing. But think, and Adam seems confirming this, that another important
feature of non relational dbms is the ability to
Also I meant:
emit([year, month, day, doc.user_agent], 1);
of course ;)
Kevin
From: Paul Davis [paul.joseph.da...@gmail.com]
Sent: Monday, October 26, 2009 1:38 PM
To: user@couchdb.apache.org
Subject: Re: Size of view file
Ryan,
Kevin's got it right
Hi.
I wrote the article to introduce CouchDB toward Japanese people.
@IT's site Let's make cocktail book on CouchDB !!
http://www.atmarkit.co.jp/fdb/rensai/09_couchdb/02/couchdb01.html
@IT is Japanese pupular site for technical engineer.
Bye.
z.ohnami
18 matches
Mail list logo
