Re: Elixir
I spent a (somewhat painful) weekend messing around with it - it basically reads like a bit of an unholy cross of _javascript_, Ruby, and erlang. The "somewhat painful" bit is that both JS and Ruby give me hives (not as much as Java, but I 've suffered through *that* since 95). Anyhow, the pseudo-OO nature is ok, if you like that sort of thing, and the 'language simplification" kinda sorta works, but I was basically left with an overwhelming feeling of "why?". There does seem to be an awful lot of "Make XXX work like Ruby" going on out there :-)Again, I'm a perl/erlang guy, so take *all* the above with a huge pinch of salt...cheers Mahesh Paolini-SubramanyaCTO Vocalocity - Powering Small Business1375 Peachtree St. NE, Suite 200, Atlanta, GA 30309 USAOffice 312.281.9923mah...@vocalocity.com | www.vocalocity.com On Mar 2, 2012, at 2:15 PM, Noah Slater wrote:Yo,What do peeps make of this:http://elixir-lang.org/Thanks,N
Re: The Future
Part of the issue w/ couchDB in the recent past is that it got good enough, and that was, well, good enough for a lot of people (I offer myself up as candidate A). To put this in Marketing-Speak, in the Technology Adoption Lifecycle, we got to the 'Early Adopter' stage, but never managed to quite make it across the chasm to the 'Early Majority' stage. To put this differently, we got to a place where the product was good enough to satisfy the Visionaries - who 'got it', and worked around any pesky inconveniences that popped up because they 'got it'. However, it was never good enough to satisfy the Pragmatists (who, face it, don't want to have to work around stuff) (Where am I going with this? Hang on...) So, to Mikeal's point about leadership - its not that there is any lack of leadership - there is plenty of it. Its just that leadership comes in many forms, and in the growth of any kind of disruptive product (which this was / is), the type of leadership necessary changes as it moves along the Technology Adoption Curve. A quick perusal of users/dev shows that there tend to be many discussions about point-features, and most of these tend to get resolved fairly easily. So leadership in the technical/technological sense - Yes. But thats pretty much where things tend to stop - i really don't see any person (or group of people) blasting through town with a banner saying Excelsior! In short, Vision Leadership does tend to be somewhat in short supply. All that said, I don't think this is really any kind of major crisis. To paraphrase Benoit, its all noise, and not very interesting noise at that. There is clearly a group of people doing 'stuff', and quite happily doing it at that. Get some releases out, talk about whats in the releases, and just as importantly, what these features do and who is using them, and a lot of the vision will pretty much make itself self-evident. Cheers Mahesh Paolini-Subramanya That Tall Bald Indian Guy... Google+ | Blog | Twitter On Jan 7, 2012, at 2:55 AM, Mikeal Rogers wrote: > Ok, we're on the same page on one thing, there is a problem. One release in a > year with this many great people contributing is not acceptable. > > Sure, my experience makes me believe, and I guess Damien's frustrations echo, > that part of this problem is Apache process. You may not agree with that, but > if you don't, and you admit that there *is* a problem, then what is it? > > The first step in CouchDB's 12 step program to get get it's mojo back has to > be admitting that it has a problem. > > As much as it's a problem, I don't think that lack of leadership is the real > problem, I think it's a symptom. I'm glad to see you say that we should get > up and do more. > > If you're stepping up to take on more leadership, say it, scream it! Own it! > > -Mikeal > > On Jan 6, 2012, at January 6, 20121:13 PM, Noah Slater wrote: > >> I have drafted a few responses to this. >> >> At the core of all of them is one central point. This has nothing to do >> with our consensus based approach. I find it frustrating that Damien >> mentioned the Apache consensus based model as a concern, when to the best >> of my knowledge he has not had any problems getting any feature he wants in >> to CouchDB. I find it even more frustrating that you've used this as an >> excuse to trot out your favorite hobby horse. Most people are aware of your >> problems with Apache, but I don't think it's very helpful to bring them up >> now, when they are tangental at best. >> >> I do, however, agree that CouchDB could do with a bit more leadership. I >> think we could do with being a bit more bold. Back in the old days, Jan >> used to say it was easier to ask forgiveness than it was to ask permission. >> I think that these days, we're too busy asking for permission most of the >> time. I agree that there needs to be an attitude change within our ranks. >> Be bold people! That's what I'll be doing with the website, shortly. >> >> On Fri, Jan 6, 2012 at 8:08 PM, Mikeal Rogers wrote: >> >>> The title of this reply is "Tough Love". >>> >>> On Jan 6, 2012, at January 6, 20129:08 AM, Noah Slater wrote: >>> >>>> Dear Community, >>>> >>>> As some of you may have already read, Damien Katz, Apache CouchDB’s >>>> original developer, has publicly announced that he intends to focus his >>>> time exclusively on developing other products for his company. Damien has >>>> had very little involvement in the CouchDB project for a year or more >>&g
Re: [ANNOUNCE] Apache CouchDB 1.1.0 has been released
Thanx all!cheers Mahesh Paolini-Subramanya | CTO | mah...@aptela.com | 703.386.1500 Ext. 9100593 Herndon Parkway | Suite 400 | Herndon, VA | www.aptela.comCheck out our Blog | Follow us on Twitter | Refer a Friend On Jun 6, 2011, at 8:13 AM, Robert Newson wrote:Hello,Apache CouchDB 1.1.0 has been released and is available for download: http://couchdb.apache.org/downloads.htmlChanges in this release: * Native SSL support. * Added support for HTTP range requests for attachments. * Added built-in filters for `_changes`: `_doc_ids` and `_design`. * Added configuration option for TCP_NODELAY aka "Nagle". * Allow wildcards in vhosts definitions. * More granular ETag support for views. * More flexible URL rewriter. * Added OS Process module to manage daemons outside of CouchDB. * Added HTTP Proxy handler for more scalable externals. * Added `_replicator` database to manage replications. * Multiple micro-optimizations when reading data. * Added CommonJS support to map functions. * Added `stale=update_after` query option that triggers a view update after returning a `stale=ok` response. * More explicit error messages when it's not possible to access a file due to lack of permissions. * Added a "change password"-feature to Futon.Apache CouchDB is a document-oriented database that can be queried and indexedin a MapReduce fashion using _javascript_. CouchDB also offers incrementalreplication with bi-directional conflict detection and resolution.CouchDB provides a RESTful JSON API than can be accessed from any environmentthat allows HTTP requests. There are myriad third-party client libraries thatmake this even easier from your programming language of choice. CouchDB's builtin Web administration console speaks directly to the database using HTTPrequests issued from your browser.CouchDB is written in Erlang, a robust functional programming language ideal forbuilding concurrent distributed systems. Erlang allows for a flexible designthat is easily scalable and readily extensible.Your Eternal ServantRobert Newson
Re: CouchOne + Membase = Couchbase
Good luck!cheers Mahesh Paolini-Subramanya | CTO | mah...@aptela.com | 703.386.1500 Ext. 91002250 Corporate Park Drive | Suite 150 | Herndon, VA | www.aptela.comCheck out our Blog | Follow us on Twitter | Refer a Friend On Feb 8, 2011, at 2:41 AM, Dirkjan Ochtman wrote:Congratulations to all of you!On Tue, Feb 8, 2011 at 07:41, Jan Lehnardt <j...@apache.org> wrote:Instead of dwelling on the merger or technology, I'd like to address likely questions about the relationship between Couchbase and Apache CouchDB. It is simple, really: at CouchOne we were 100% committed on the Open Source side of things and at Couchbase we will continue to do so at the same degree. In terms of organisation, Couchbase will be it's own independent Open Source project that has Apache CouchDB and memcached as dependencies, but adds a few things of its own that warrant being its own project. Our combined engineering team, led by Damien, will continue to contribute to Apache CouchDB in the same way as we've been to date, only more. I can't wait to share with you what we'll come up with :)And thanks for this summary of the technical side of things.Cheers,Dirkjan
Re: Introducing CouchDB Ltd.
I have to agree with Antony/Benoit here. Again, I'm quite aware of all the opposing examples, but in the end I have a bit of a philosophical issue vis-a-vis having to recommend CouchDB.org vs CouchDB.com, etc. Of course, obligatory caveats apply all over the place (I appreciate the work Jan et. al have put in, we're strongly (if somewhat silently) using CouchDB across most of our application base, etc. etc.) Cheers --- Mahesh Paolini-Subramanya CTO, Aptela Inc. (703.386.1500 x9100) http://www.aptela.com On Mar 8, 2009, at 11:33 AM, Antony Blakey wrote: On 08/03/2009, at 11:47 PM, Benoit Chesneau wrote: That said. I just would like to add i'm not against such service. That's not the point. I like this idee and I hope it will work for you. What I dislike, and I'm strongly against it, is that you use couchdb name for **your** service. For me that mean i have to reconsider the way I endorse couchdb in my projects and I feel bad. I really hope you don't already make any legal administrative stuff about it and that your are ok to change/think about another name.
Re: Proposal: Extending immutability
+1 --- Mahesh Paolini-Subramanya CTO, Aptela Inc. (703.386.1500 x9100) http://www.aptela.com On Jan 5, 2009, at 8:26 AM, Antony Blakey wrote: I've cc'd this to couchdb-user, because I think this discussion belongs on -dev, but everyone watches -user. One of the great features of Couch is the use of optimistic locking i.e. rev as a bedrock mechanism, and the way this is permeated through the API. The combination of id + rev is a reference to an immutable value (with some caveats, one subject of this proposal). This means that you get caching for free. By keying off id + rev, you can cache the document along with any (functional) derived values. Additionally you can trivially memoize functions of multiple documents using that mechanism. I use this to good effect in my application, where I aggressively cache the documents (which are sometimes large) and therefore don't need the document content in queries. To take advantage of this however this means that my views need to include the _rev as the value, and transformation that would normally happen in the map happens in the client. It would be very useful to have the rev returned wherever an id is returned, specifically in view results. You could then use a view without include_docs, and get the ids and revs. You can keep a cache (per view, pre db) of the results. The actual view results only need to be fetched on a cache miss, which can be driven by the cache machinery. The nice thing is that all of this caching machinery can be transparently interposed. Except when the view definition is changed. So I also propose to have the rev and id of the design doc returned in the view results. And for completeness, every database should be assigned a UUID when it is created. This UUID should be provided in the dbinfo, and for every view and view-like result. This means that from every view result you can construct a list of universally unique references to immutable values e.g. DB UUID + (View id + rev) + (Document id + rev). A form of referential transparency - and with a cache and a little bit of 100% generic machinery, it can be true referential transparency. Clients don't have to watch/be notified about changes to design docs, or even database creation/deletion. Systemwide transparent caching in particular becomes trivial. So, in summary I propose: 1. Provide the document rev whenever the id is returned, such as view results i.e. not in the document, but in the per-row hash. 2. Provide the design document id and rev in view results i.e. in the top level hash. 3. Add a UUID to databases, and provide that in view results i.e. in the top level hash, and all other database operation results. I think you could do this even with reduce results, but I haven't though a lot about it. I think this generalised the current API in a very useful way, that will greatly simplify, and hence 'robustify' client code. Although I haven't checked the implementation code, my experience so far suggest this isn't difficult. Antony Blakey - CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Every task involves constraint, Solve the thing without complaint; There are magic links and chains Forged to loose our rigid brains. Structures, structures, though they bind, Strangely liberate the mind. -- James Fallen
