Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 49235 invoked from network); 22 Feb 2011 16:59:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 22 Feb 2011 16:59:03 -0000 Received: (qmail 17722 invoked by uid 500); 22 Feb 2011 16:59:03 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 17589 invoked by uid 500); 22 Feb 2011 16:59:01 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 17581 invoked by uid 99); 22 Feb 2011 16:59:01 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Feb 2011 16:59:01 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.160.180 as permitted sender) Received: from [209.85.160.180] (HELO mail-gy0-f180.google.com) (209.85.160.180) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Feb 2011 16:58:56 +0000 Received: by gyd5 with SMTP id 5so561377gyd.11 for ; Tue, 22 Feb 2011 08:58:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=wkYcWKDRvzHZOzKJDrQsjDxCBI/9dHO0ZFVcsc9hvkE=; b=R5WzjD0eNvzCIE9zyaiklajrriIzhdp6vYgGrLBYO8TuQl5lp3qXfryyuQBGwYbUz+ Q1xt2ucH9CJziJli2STtWz13ZazHjXZiAda5LZRtvToAk56PjH8LPsHEV8o8fbZ6jNbI 4Jx12aTy0+4qjL4xV0ypZ6uqSDRirM83llU98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=GE3HBkhWhgVrtPHGfg3F1OfOnvY+2KIraMqSQZ2ll7PBTr3j4AM/wmuysWmWf69LRl NqTq5t0QSp3Vg25l1xgJ+kjd2xX30mVtEG7UsohlhWz16eJuXzyNX1xNiUw4bQAZIm70 X1gXmpViFYkm+3jcSZ3UYGkJUtgmucrqsGZPc= Received: by 10.236.102.161 with SMTP id d21mr5198943yhg.82.1298393915894; Tue, 22 Feb 2011 08:58:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.147.40.17 with HTTP; Tue, 22 Feb 2011 08:57:53 -0800 (PST) In-Reply-To: References: From: Paul Davis Date: Tue, 22 Feb 2011 11:57:53 -0500 Message-ID: Subject: Re: CommonJS module updates To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 22, 2011 at 11:47 AM, Caolan McMahon wrote: > As some of you may know, I've been working on a couchapp framework > which makes heavy use of commonjs modules (http://kansojs.org). While > developing this I've run into a number of issues which prevent the use > of some modules, and makes writing my own more difficult: > > 1. Modules are not cached - eval'ing a complex application, consisting > of many modules on each request would have an impact on performance. > It also means you can't use modules which use the module object to > store state. This is commonly used by template libraries to store > loaded templates in a cache, or 'memoize' expensive functions. > > 2. Circular dependencies blow the stack - Its not possible to require > module A from module B, if module B also requires module A. This > happens more often than you might think, and is handled by other > require() implementations by setting the cached module to an empty > object before eval'ing it. The fix for this requires a module cache to > be in place. > > > Since these are really hindering progress, I've forked on github and > committed my proposed patches with associated tests: > https://github.com/caolan/couchdb/compare/7f553e82ef...6c66675a23 > > Please, if you have time, review the code and provide me with your feedback. > > > Thanks, > > Caolan > The circular dependency section looks good. The bit on caching and testing that things are cached is not good on the other hand. The way that JS processes are used you can never be sure if it'll be the same os process handling the request. In the test suite, its more than likely to be the same OS process because of how the server gets restarted often and there's a single serialized client. I'm a bit iffy on whether we should cache modules because that'd be a pretty easy place to break view updates and could lead to other weird bits in the show/list stuff. Though I also understand the concern for avoiding all the recompilation. I wonder, is it possible to freeze the module maybe?