couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriel Farrell <gsf...@gmail.com>
Subject Re: LivelyCouch - a framework around CouchDB and Node.js
Date Mon, 08 Nov 2010 22:56:53 GMT
On Mon, Nov 8, 2010 at 5:45 PM, Mirko Kiefer <mirko.kiefer@arcor.de> wrote:
> Moving the handlers to design documents shouldn't be a problem.
> You would then probably want to call a URL like:
> http://127.0.0.1:5984/_handler/yourdb/_design/designdoc/handlername
>
> We decided to have a separate handler DB as one of our main motivations was
> to be able to do requests across databases. Also, at the moment we
> constantly keep a worker running who writes out handler code to the file
> system everytime it changes. Handlers are then executed from there. If you
> split your handler code across databases you would have to listen to changes
> on each of them.
> The reason we write out the code is that we couldn't find an easy solution
> to handle dependencies of your handler - if you do a "require" in your node
> code, the required file needs to be found.

Those reasons are sound. Awesome that the system has the flexibility
to handle different setups, too.

> I haven't seen Mikeal's talk but going to have a look right now.
> Not sure if I understand you right - in LivelyCouch you could do something
> like:
> - have a Worker running who listens on _changes of a database
> - when a change happens the worker would send out a message
> - other Workers could be triggered by this depending of your definition in
> the Event documents

Sounds like LivelyCouch also has the flexibility to handle what I was
thinking here. The example Mikeal gives is email, where a changed or
new document in _changes signals that an email should be sent. After
the email is sent, node would then update that same document to signal
that the email had been sent.


> On 11/8/10 11:09 PM, Gabriel Farrell wrote:
>>
>> Neat. I look forward to both using the framework and learning from its
>> use of externals and http proxy modules. Comments:
>>
>> Because the handlers are similar to views, I'm tempted to want them in
>> my design documents. Would it be possible to read them from a
>> "handlers" value there?
>>
>> I think that URL example at the end of Part 1 should be
>> "filtered_people" instead of "blond_people".
>>
>> I like the way Mikeal talked about triggering events in his "Crazy
>> Delicious" talk at JSConf by giving each trigger its own document,
>> firing events off a long poll of _changes, then updating that document
>> with event responses. How would LivelyCouch notify an app with event
>> responses?
>>
>>
>> Gabriel
>>
>> On Mon, Nov 8, 2010 at 4:24 PM, Mirko Kiefer<mirko.kiefer@arcor.de>
>>  wrote:
>>>
>>> Hi,
>>> we are currently working on open sourcing our so called LivelyCouch
>>> framework which emerged out of a few projects.
>>> Hopefully this week still we will have a website up and running
>>> explaining
>>> the usage of LivelyCouch in more detail.
>>> I would just like to get some early feedback on our concepts - so I wrote
>>> a
>>> little summary in two parts on my blog.
>>>
>>> The first part focuses on writing Node.js handlers:
>>>
>>> http://mirkokiefer.com/blog/2010/11/introducing-livelycouch-part-1-writing-node-js-handler/
>>>
>>> Part two explains the event system we built around CouchDB using Node:
>>>
>>> http://mirkokiefer.com/blog/2010/11/introducing-livelycouch-part-2-events-and-workers/
>>>
>>> Hope to get a lot of feedback!
>>>
>>> Mirko
>>>
>

Mime
View raw message