On Mon, Nov 8, 2010 at 5:45 PM, Mirko Kiefer <[email protected]> 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<[email protected]> >> 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 >>> >
