Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of stephenp@agrussell.com
 designates 204.251.33.236 as permitted sender)
Message-Id: <96FCEE6E-A69F-49EE-92BA-AADFEA42C523@agrussell.com>
From: Stephen Prater <stephenp@agrussell.com>
To: dev@couchdb.apache.org
In-Reply-To: <AANLkTinVKua2fXBc35AQV49FHQmbcrAaP792PX63umJ4@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: CommonJS in map and reduce
Date: Mon, 20 Sep 2010 11:15:58 -0500
References: <AANLkTindw0dUJsnEsbC5e5Q_fnrSkt_3Y6eChy=Xq-Mo@mail.gmail.com>
 <665BD290-CD33-41FB-B6E4-3587E9031C22@agrussell.com>
 <AANLkTinVKua2fXBc35AQV49FHQmbcrAaP792PX63umJ4@mail.gmail.com>

Actually, upon further inspection I think this is probably closer to a  
Ruby's "include" than it is to "require" - which is a good thing.

At some point, the view server will be required to compile/eval  
whatever code is in the "lib" element, no?

Would it do this separately from compiling the views themselves?   I'm  
not entirely clear on how the CommonJS module system is supposed to  
behave here.

Obviously, any "lib" code in a Ruby view server, would have to be  
written in Ruby, and not JS.

stephen

On Sep 20, 2010, at 10:44 AM, Mikeal Rogers wrote:

> CommonJS modules are javascript specific.
>
> The only *special* thing we would be doing is saying that an  
> attribute on
> views that doesn't have a "map" attribute won't be considered a  
> valid map
> function but will be used in the hash. That's easily portable to other
> languages if you are embedding the modules in the design document.
>
> -Mikeal
>
> On Mon, Sep 20, 2010 at 5:16 PM, Stephen Prater <stephenp@agrussell.com 
> >wrote:
>
>> Would this implementation be view server agnostic?
>>
>> How would it work with (say, theoretically) the Ruby view server?
>>
>> Although it's much harder to enforce the "don't import" rule in  
>> languages
>> other than javascript, it would be nice to provide a "blessed" way  
>> to do a
>> require for your view.
>>
>>
>> On Sep 20, 2010, at 9:55 AM, Chris Anderson wrote:
>>
>> Devs,
>>>
>>> Mikeal and I were talking and we came up with a sane way to do
>>> CommonJS in map and reduce.
>>>
>>> Refresher: we don't have CommonJS require there now because the
>>> current CommonJS implementation is scoped to the whole design doc,  
>>> and
>>> giving views access to load code from anywhere in the design doc  
>>> would
>>> mean we'd have to blow away your view index anytime you changed
>>> anything. Having to rebuild views from scratch just because you
>>> changed some CSS or a show function isn't fun,so we avoided the  
>>> issue
>>> by keeping CommonJS require out of map and reduce altogether.
>>>
>>> The solution we came up with is to allow CommonJS inside map and
>>> reduce funs, but only of libraries that are stored inside the views
>>> part of the design doc.
>>>
>>> So you could continue to access CommonJS code in design_doc.foo,  
>>> from
>>> your list functions etc, but we'd add the ability to require  
>>> CommonJS
>>> modules within map and reduce, but only from design_doc.views.lib
>>>
>>> There's no worry here about namespace collisions, as Couch just  
>>> plucks
>>> views.*.map and views.*.reduce out of the design doc. So you could
>>> have a view called "lib" if you wanted, and still have CommonJS  
>>> stored
>>> in views.lib.sha1 and views.lib.stemmer if you wanted.
>>>
>>> We could allow CommonJS modules to be stored anywhere in ddoc.views,
>>> but I think it will simplify the implementation to enforce that they
>>> be stored in views.lib -- if people think that is too restrictive,
>>> please speak up now, otherwise I'll start to implement this.
>>>
>>> Chris
>>>
>>>
>>> --
>>> Chris Anderson
>>> http://jchrisa.net
>>> http://couch.io
>>>
>>>
>>