Good call. +1 for two reasons
- lack of scheduler transparency for long-running NIFs - small core === better innovation through plugins & friends Benoit - where do you see this sitting between merges (bigcouch/refuge), build improvements etc? A+ Dave On 19 September 2013 12:05, Alexander Shorin <[email protected]> wrote: > Good call. +1 > -- > ,,,^..^,,, > > > On Thu, Sep 19, 2013 at 1:59 PM, Jason Smith <[email protected]> wrote: >> +1 >> >> Some sort of "CouchDB Core" project or something? >> >> >> On Thu, Sep 19, 2013 at 4:51 PM, Benoit Chesneau <[email protected]>wrote: >> >>> Hi, >>> >>> I am thinking to make all this extra C optional in couchdb. By extra C I >>> mean: >>> >>> - snappy compression >>> - couch compare function using ICU >>> - JS views >>> - JSON encoding >>> >>> Basically anything that is not included in the erlang standard library or >>> not in Erlang. The reason for that is to allow a simple distribution on >>> different platforms or vms things like erlangonxen. Also it would improve a >>> lot the way we can upgrade a full release or change a module live. >>> >>> First one is easy, the second I don't know I guess we can have a more >>> simpler binary comparison is possible or maybe better providing a pure >>> erlang implementation of it using ux [1] wich is probably enough faster for >>> our need (we only require to compare ids or keys). >>> >>> We mostly have JS because it's easy to handle for an end-developer and also >>> trendy among some circles. But i think we could provide here another >>> default. That can be elixir [2] or lua using luerl module [3]. The second >>> one may be the easier since it is also provide for free the sandbox we are >>> supposed to have in JS. Not sure it is easy to do with elixir. >>> >>> >>> Thoughts? >>> >>> - benoit >>> >>> [1] https://github.com/erlang-unicode/ux >>> [2] http://elixir-lang.org/ >>> [3] https://github.com/rvirding/luerl >>>
