couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: permanent replications API discussion
Date Sun, 31 May 2009 03:08:56 GMT
On Sat, May 30, 2009 at 7:05 PM, Randall Leeds <randall.leeds@gmail.com> wrote:
> On Sat, May 30, 2009 at 18:11, Damien Katz <damien@apache.org> wrote:
>>
>> Some random thoughts.
>

Hey here's my random one about cron. We build a Task Manager that's a
browser page that runs tasks like processing a view pool to keep it
empty, etc. It's not hard to keep cron running as long as the tasks
themselves are crash-only, because reloading the page is a pretty
effective reset, and JavaScript can auto-reload the page occasionally.

Applications can register tasks by putting them into a design doc
under the tasks field. This way users (database owners) can allow
tasks to run on a per task basis. Installing a new task into the
active set is a sensible place for security warnings and approvals by
the user.

There is also the option to do basically the same thing, but run the
tasks on the server using couchjs's http capabilities. In this case
the node administrator would control the active tasks list.

Tasks that use the couch.js (synchronous test suite Ajax lib) will be
portable transparently to the server side.

Too crazy?

Chris

>
> Me too.
>
> Maybe there should be validation hooks. For instance, the existing system
> for update validation might run the first step of a consensus instance
> between several permanent replicas to decide [_seq, _rev]. Upon gathering
> <accept> messages the leader could commit locally and reply to the client.
> At this point the other replicas are waiting for the document information,
> but know from whom it should come and what sequence and revision number it
> should be assigned. While secure environments might guarantee no change gets
> replicated unless it was the consensus winner, insecure environments might
> have servers which lie and push replication changes unilaterally. A
> validation hook could check to make sure that the replicated document was
> proposed by server X at some time with [_seq, _rev].
>
> These validation functions could even live in the replication settings
> database.
>
> -Randall
>



-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message