incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mirko Kiefer <mirko.kie...@arcor.de>
Subject Re: LivelyCouch - a framework around CouchDB and Node.js
Date Fri, 10 Dec 2010 10:35:36 GMT
Hi Florian,

running LivelyCouch on the client-side is an option, but as you say only 
possible with Cygwin on Windows.
Our main intention with LivelyCouch is to use it as a server-side thing. 
If you would run an app on the server you would only have one site to 
speak to as LivelyCouch runs behind CouchDB using it as a proxy.

If you plan to use CouchDB on the client anyway, you may think about 
combining both. As you can't do cross-site request from the browser you 
could for example use CouchDB's replication to "communicate" to your server.
You could for example have a "message" database on your client that gets 
continuously replicated to the server.
On the server you could then use LivelyCouch with a changelistener that 
triggers some actions whenever new documents arrive...
Don't know your use case so maybe that doesn't make sense to you.

Mirko

On 12/10/10 3:42 AM, Florian Leitner wrote:
> Hi Mirko,
>
> As I never used node.js, I gave it a look just now - and found
> something rather worrying with respect to my needs: node.js does not
> support Windows (natively, only via Cygwin), and after checking their
> mailing list, it seems the developers behind node.js are not planning
> any support for it, either - and not even much for their "Cygwin
> port". So, essentially, a LivelyCouch app can only run on Mac and
> Linux, right? (Not that I like or even support Windoze, but I assume
> many users of a desktop-based application using CouchDB will...)
>
> --Florian
>
> On 10 December 2010 02:53, Florian Leitner<florian.leitner@gmail.com>  wrote:
>> Hi Mirko,
>>
>> Your project sounds pretty much exactly like what I am looking for; I
>> have posted an issue about my cross-site XHR requests for the
>> couch-based application I am about to develop in a recent post
>> ("CouchDB/App, XHR, and the JavaScript Same Origin Policy"). So, if I
>> understand what you propose on the LivelyCouch website, this would
>> _exactly_ solve my issues, right? Because of using node.js as
>> "man-in-the-middle" between the browser and the CouchDB, I can do any
>> XHR to any site without having to think about Same Origin
>> Policy-stuff. On the other hand, because a LivelyCouch app is fully
>> stored inside CouchDB, installing (replicating) and updating
>> (synchronizing) such an app stays as trivial as it is with CouchApp.
>> Is this correct?
>>
>> Thanks,
>> Florian
>>
>> On 7 December 2010 18:55, Mirko Kiefer<mirko.kiefer@arcor.de>  wrote:
>>> Hey,
>>> we've been heavily working on getting LivelyCouch to a usable state for the
>>> CouchDB and Node.js community.
>>> You can now find the source and a first tutorial on the project site:
>>> http://www.livelycouch.org
>>>
>>> A second more advanced tutorial will follow tomorrow. Mikeal, if you don't
>>> mind I will borrow your e-mail outbox scenario from the js conference in
>>> Berlin - it suits perfectly as a LivelyCouch use case :)
>>>
>>> Best,
>>> Mirko
>>>
>>> On 11/8/10 11:11 PM, Mikeal Rogers wrote:
>>>> Yeah, this stuff is amazing because it implements things that were in my
>>>> head and I didn't write it :)
>>>>
>>>> I'm super happy right now ;)
>>>>
>>>> On Mon, Nov 8, 2010 at 2:09 PM, Gabriel Farrell<gsf747@gmail.com> 
  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