couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: CommonJS module updates
Date Tue, 22 Feb 2011 18:08:04 GMT
On Tue, Feb 22, 2011 at 12:20 PM, Caolan McMahon
<caolan.mcmahon@gmail.com> wrote:
> I can see the case for not wanting to store state on modules between
> requests, as this could break caching rules for those resources. Even
> though there is a performance hit. How would you know if the results
> for a show or list function had changed?
>
> It also sounds like this would be unreliable anyway since there are
> multiple JS processes. However, I think we must have caching between
> require()'s within a single request, as otherwise some modules will
> not work and we can't handle circular dependencies.
>
> The question is, should CouchDB enforce the fact that applications
> should not store state between requests (except for caching) and take
> the performance hit, or should this be left to commonjs module
> developers?
>

Yeah, I'm not entirely sure on this point. Technically you can already
do some pretty weird things if you're determined enough, but with the
module cacheing I think that line becomes less obvious.

> I assume freezing modules would cancel out the benefits of increased
> module compatability...
>

Yeah, I don't think its the perfect solution either. It seems like the
sort of thing that would randomly break various modules.

>
> On 22 February 2011 16:57, Paul Davis <paul.joseph.davis@gmail.com> wrote:
>> On Tue, Feb 22, 2011 at 11:47 AM, Caolan McMahon
>> <caolan.mcmahon@gmail.com> 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?
>>
>

Mime
View raw message