Confusion over what CouchDB is has more to do with a lack of clarity on the
website and conveyed by the project itself than anything Cloudant, CouchBase,
or any other company has done building products around it.
Renaming it does not solve this, it just creates a new name/entity people
it KillerDB, AwesomeDB, whatever and
then get back to relaxing :)
Again, just my thoughts. Just trying to get the wheels churning on
alternatives to getting in some spat with CouchBase, continuing to confuse
everyone, etc...
James
On Feb 20, 2012, at 12:34 PM, Mikeal Rogers
vision and the project has
always had a variety of different visions for what it should be.
-Mikeal
On Feb 20, 2012, at February 20, 20122:39 PM, Noah Slater wrote:
On Mon, Feb 20, 2012 at 10:32 PM, Mikeal Rogers
mikeal.rog...@gmail.comwrote:
This is why there is confusion:
What
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
.
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 mikeal.rog...@gmail.comwrote:
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
For what it's worth, i read all the articles I got via Google Alerts and the
response actually seems to be 50/50.
About half noted Koco's response and Damiens inactivity over the last year and
the other half were people flipping out and even asserting things that weren't
in Damien's blog post
you should make this a blog post so that I can link to it :)
On Nov 30, 2011, at November 30, 20119:43 AM, Jan Lehnardt wrote:
Apache CouchDB is Alive and Kicking
“The reports of my death are greatly exaggerated.” — Mark Twain
In the past days at the end of November 2011, a few news
There is an API to write the resolution which is not documented. The workflow
is also undocumented. Randall promised he would write it up after he finishes
the rewrites on PouchDB.
On Nov 22, 2011, at November 22, 20114:34 PM, Robert Newson wrote:
There isn't one. There's only an algorithm to
Is the expectation that *all* of the concerns added to this page will be
resolved?
On Nov 17, 2011, at November 17, 20:48 AM, Christian Grobmeier wrote:
Hello all,
i have had a long discussion on members@ recently on couchdb and git.
I am also here to help.
My main concern was, that
Every style guide, and every linter, has a different notion about spacing. All
of them use spaces of course but the actual indentation varies.
2 spaces is fairly standard and damn near the entire world uses it. There are
other variations, like 4 spaces for multi-line var which closure-lint
4 space is standard in a lot of language but most programmers vary style
between languages. Python people are pretty opinionated about syntax and style
and tend to be more resistant especially when writing JavaScript because the
languages are so similar.
The indentation thread is a little too indented :)
I've been working for some time now on a rewrite of Futon. It's not in a
state we can start working on a merge in to trunk. I don't have any known
bugs and all the features are there although I'm sure there are some UI
tweaks we'll want to continue to make.
I've added a JIRA ticket and a patch
I just setup a new laptop and used homebrew to install the CouchDB deps
(spidermonkey erlang).
Not only was it super fast and painless but I got a newer spidermonkey
(1.8.3) which is something like 30x faster for most of the stuff we do with
the view server but I also didn't have to pass any
recommended, but I think that purging all references to MacPorts might
be excessive.
On the other hand, how hard is it to figure out how to type 'sudo port
install couchdb'?
On Oct 27, 2010, at 4:03 PM, Mikeal Rogers wrote:
I just setup a new laptop and used homebrew to install the CouchDB deps
I'm working on the new Futon code and I've started working through the view
builder.
One goal I have is to morph this interface from primarily being used for
creating map/reduce functions to an interface for creating queries against
your views since we tend to get more questions about creating
One of the things I'll eventually add to the new futon is a diagnostics
page.
This *should* take over for the test suite on the right sidebar. The test
suite will be somewhere else linked on that page and won't be for people who
aren't developing *on* CouchDB.
At least that's the idea. Big
This has been brought up a few times but I think it's about time we come up
with a real plan to solve it.
CouchDB currently can't add access control headers for cross site HTTP
requests from the browser for anything other than show and list. That means
all the regular API calls as well as
Didn't some other replicator improvements make it in as well like streamed
attachments?
On Tue, Oct 5, 2010 at 9:43 AM, Filipe David Manana fdman...@apache.orgwrote:
On Tue, Oct 5, 2010 at 5:31 PM, Zachary Zolton zachary.zol...@gmail.com
wrote:
For those of us not following at the commit
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
Great writeup.
The only thing I think it's lacking is how the require namespaces will
differ.
So, refresher, require('foo') means import a module that is a top level
attribute in the design doc named foo. Basically the commonjs module
namespace is scoped to the ddoc root. This will stay the same
count in the btree index to make
skip
cheap?
On Sep 12, 2010, at 9:39 AM, Mikeal Rogers wrote:
For pagination you can use the skip parameter instead of trying to
change
the startkey for each pagination.
http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options
?startkey
or skipped values in your UI. Startkey +
docid generally produces better semantics.
-Damien
On Sep 12, 2010, at 8:21 PM, Randall Leeds wrote:
Any reason why we don't put a document count in the btree index to make
skip
cheap?
On Sep 12, 2010, at 9:39 AM, Mikeal Rogers wrote
About a month back I started a little experiment to see what Futon would
look like with sammy.js
http://github.com/mikeal/couchdb/tree/sammy
What started as a small experiment has turned in to a complete rewrite. As I
moved things over to a new url and code structure using sammy I also started
One idea that was floated at least once was to replace all the code currently
have on top of mochiweb directly with webmachine.
This would make extensions and improvements follow already well defined
patterns provided by webmachine.
-Mikeal
Sent from my iPhone
On Aug 20, 2010, at 2:09 AM,
I tested the latest code in recover-couchdb and it looks great.
-Mikeal
On Thu, Aug 12, 2010 at 2:33 PM, J Chris Anderson jch...@apache.org wrote:
On Aug 12, 2010, at 2:15 PM, J Chris Anderson wrote:
On Aug 12, 2010, at 12:36 PM, Adam Kocoloski wrote:
Right, and jchris' db_repair
://github.com/kocolosk/couchdb/tree/db_repair
Adam
On Aug 9, 2010, at 9:50 PM, Mikeal Rogers wrote:
I pulled down the latest code from Adam's branch @
7080ff72baa329cf6c4be2a79e71a41f744ed93b.
Running timer:tc(couch_db_repair, make_lost_and_found,
[multi_conflict]).
on a database
I have some timing number for the new code.
multi_conflict has 200 lost documents and 201 documents total after
recovery.
1 timer:tc(couch_db_repair, make_lost_and_found, [multi_conflict]).
{25217069,ok}
25 seconds
Something funky is going on here. Investigating.
1 timer:tc(couch_db_repair,
, Mikeal Rogers mikeal.rog...@gmail.comwrote:
Found one issue, we weren't picking up design docs because it didn't have
admin privileges.
Adam fixed it and pushed and I've verified that it works now.
I wrote a little node script to show all recovered documents and expose any
documents that didn't
I'm starting to create a bunch of test db files that expose this bug under
different conditions like multiple restarts, across compaction, variances in
updates the might cause conflict, etc.
http://github.com/mikeal/couchtest
The README outlines what was done to the db's and what needs to be
, Mikeal Rogers mikeal.rog...@gmail.com
wrote:
I'm starting to create a bunch of test db files that expose this bug
under
different conditions like multiple restarts, across compaction, variances
in
updates the might cause conflict, etc.
http://github.com/mikeal/couchtest
The README
jchris suggested on IRC that I try a normal doc update and see if that fixes
it.
It does. After a new doc was created the dbinfo doc count was back to
normal.
-Mikeal
On Mon, Aug 9, 2010 at 1:39 PM, Mikeal Rogers mikeal.rog...@gmail.comwrote:
Ok, I pulled down this code and tested against
couch_db_repair:find_nodes_quickly/1 that reads 1MB chunks as binary
and tries to process it to find nodes instead of scanning back one
byte at a time. It is currently not hooked up to the repair mechanism.
Making progress. Go team.
On Mon, Aug 9, 2010 at 13:52, Mikeal Rogers mikeal.rog...@gmail.com
Back up a few steps.
The view server line protocol while being terribly defined and taking
breaking changes in almost every release has still maintained a fair amount
of alternate implementations in languages other than JavaScript. I seriously
doubt that we would see this kind of diverse
returns a reference to itself and the view
server can now accept a validate_update_doc call and then will need to call
back in to the referenced update function held by the view server.
-Mikeal
On Mon, Aug 2, 2010 at 11:49 AM, Mikeal Rogers mikeal.rog...@gmail.comwrote:
Back up a few steps
Moving the js process and the *new* view server interaction protocol in to
erlang is what I meant by this.
On Mon, Aug 2, 2010 at 11:58 AM, Jason Smith j...@couch.io wrote:
On Tue, Aug 3, 2010 at 01:49, Mikeal Rogers mikeal.rog...@gmail.com
wrote:
Back up a few steps.
Totally agree
For the first point about CommonJS modules in Map/Reduce views I'd say
the goal is fine, but I don't understand how or why you'd want that
hash to happen in JavaScript. Unless I'm mistaken, aren't the import
statements executable JS? As in, is there any requirement that you
couldn't import a
On Mon, Aug 2, 2010 at 12:52 PM, J Chris Anderson jch...@apache.org wrote:
On Aug 2, 2010, at 12:09 PM, Jason Smith wrote:
On Tue, Aug 3, 2010 at 02:01, Mikeal Rogers mikeal.rog...@gmail.com
wrote:
Moving the js process and the *new* view server interaction protocol in
to
erlang
On Mon, Aug 2, 2010 at 1:02 PM, Benoit Chesneau bchesn...@gmail.com wrote:
On Mon, Aug 2, 2010 at 8:56 PM, Mikeal Rogers mikeal.rog...@gmail.com
wrote:
Before doing any changes to view server protocol, I would prefer to
start working on a better implementation of js insde CouchDB
On Mon, Aug 2, 2010 at 1:11 PM, Paul Davis paul.joseph.da...@gmail.comwrote:
On Mon, Aug 2, 2010 at 2:49 PM, Mikeal Rogers mikeal.rog...@gmail.com
wrote:
Back up a few steps.
The view server line protocol while being terribly defined and taking
breaking changes in almost every release
On Mon, Aug 2, 2010 at 1:18 PM, Benoit Chesneau bchesn...@gmail.com wrote:
On Mon, Aug 2, 2010 at 10:02 PM, Benoit Chesneau bchesn...@gmail.com
wrote:
On Mon, Aug 2, 2010 at 8:56 PM, Mikeal Rogers mikeal.rog...@gmail.com
wrote:
Before doing any changes to view server protocol, I would
On Mon, Aug 2, 2010 at 2:54 PM, Paul Davis paul.joseph.da...@gmail.comwrote:
On Mon, Aug 2, 2010 at 5:34 PM, Mikeal Rogers mikeal.rog...@gmail.com
wrote:
For the first point about CommonJS modules in Map/Reduce views I'd say
the goal is fine, but I don't understand how or why you'd want
I've been thinking about this a lot lately and I'm starting to think
that continuing to build on the update function isn't the best idea.
The update function just wasn't designed with this in mind.
Any way I can think of to add support for this use case to the update
function ends with a API I
update to all the HTTP and related
database calls it needs to make. Without that nobody can even build the high
level thing.
-Mikeal
On Sun, Aug 1, 2010 at 11:48 AM, J Chris Anderson jch...@apache.org wrote:
On Aug 1, 2010, at 11:46 AM, Mikeal Rogers wrote:
I've been thinking about
jchris found an issue in make that wasn't including some of the work i did
in Futon that was in a new file.
jchris do you have that commit hash handy?
-Mikeal
On Tue, Jul 27, 2010 at 3:57 PM, Robert Newson robert.new...@gmail.comwrote:
+1
It's a small change that helps people avoid a broken
After some conversations I've had in NYC this week and Mathias' great post
on the 10 biggest issues with CouchDB (
http://www.paperplanes.de/2010/7/26/10_annoying_things_about_couchdb.html )
I wanted to formally propose some changes to the view server/protocol.
The first issue I want to tackle is
On Mon, Jul 26, 2010 at 5:43 PM, J Chris Anderson jch...@apache.org wrote:
On Jul 26, 2010, at 2:35 PM, Mikeal Rogers wrote:
After some conversations I've had in NYC this week and Mathias' great
post
on the 10 biggest issues with CouchDB (
http://www.paperplanes.de/2010/7/26
Two CouchDB events in two straight days. NYC is like heaven!
There is a CouchDB meetup tomorrow, Tuesday the 27th, in NYC at 7pm at DBA,
41 First Avenue, New York City, NY. 10003. Between 2nd and 3rd Street.
And I will be speaking on Wednesday the 28th at the NYC NoSQL meetup.
I'm not seeing most of these hit planet couchdb, are these blogs added? If
not, why?
-Mikeal
On Wed, Jul 14, 2010 at 2:50 PM, Will Hartung wi...@mirthcorp.com wrote:
Here ya go..in all it glory
http://willhartung.blogspot.com/2010/07/couch-10-retrospect.html
On Wed, Jul 14, 2010 at 7:51
I'm incredibly interested in your poetry and dream logs :)
On Wed, Jul 14, 2010 at 4:15 PM, Noah Slater nsla...@tumbolia.org wrote:
On 15 Jul 2010, at 00:11, Will Hartung wrote:
Heh -- ditto -- I thought someone might aggregate links for a one time
post, but not hook me up to some
That sounds like additional work someone isn't going to do.
Featuring the planet more prominently leverages stuff we're already doing.
-Mikeal
On Sun, Jul 11, 2010 at 10:34 PM, Benoit Chesneau bchesn...@gmail.comwrote:
On Mon, Jul 12, 2010 at 7:06 AM, Mikeal Rogers mikeal.rog...@gmail.com
I've created a wiki page to serve as a whiteboard of session ideas at
CouchCamp 2010.
http://wiki.apache.org/couchdb/CouchCamp2010
Please contribute ideas and join the discussion.
-Mikeal
Just for reference, most SQL databases ship with the fsync to their log on a
1s or longer cycle, it's pretty standard.
delayed-commits on doesn't reduce durability because the writes to log are
still append-only and can survive invalid writes and crashes and all that.
Also, they don't reduce
The difference between delayed-commits on and off is not the biggest
difference in consistency and durability between mongo and couch.
MongoDB doesn't return a response by default on a write. You just write to
the socket and hope that it's available.
MongoDB lets the kernel decide to flush to
people that do binary distributions of
CouchDB (like all the linux distros) could be encouraged to turn it to false
(though I have no idea what their general policy about changing defaults
is).
Cheers,
Volker
On 07.07.2010 00:52, Mikeal Rogers wrote:
I think there is a balance
My general theory (extrapolating from my own behavior) is that no one reads
documentation.
because there isn't any, zing! j/k
i actually agree with this for the most part but it doesn't mean that there
shouldn't be any for the people that use google to figure out things :)
Maybe the
For the concurrent performance tests I wrote in relaximation it's actually
better to run with delayed_commits off because it measures the roundtrip
time of all the concurrent clients.
The reason it's enabled by default is because of apache-bench and other
single writer performance test tools.
commit)
I think this is worth discussing. I'm not strongly in favor of the
delayed_commit=true setting, but I do think it is slightly more
user-friendly...
Chris
On Jul 5, 2010, at 10:02 AM, Mikeal Rogers wrote:
For the concurrent performance tests I wrote in relaximation it's
actually
I don't know what we did, but in my tests the write performance on trunk is
about 3x faster than 0.11
http://mikeal.couchone.com/graphs/_design/app/_show/compareWriteReadTest/e69057a29bd6e4ac4ae0115fac018487
The left vertical column is the average response time in ms and the bottom
horizontal
, Damien Katz dam...@apache.org wrote:
Awesome! I think most of this is due to Adam and Randall. Nice work guys :)
-Damien
On Jul 1, 2010, at 2:48 PM, Mikeal Rogers wrote:
I don't know what we did, but in my tests the write performance on trunk
is
about 3x faster than 0.11
http
so I think that when the documents
size increases the performance of +A balances out. Also, if you had load on
more than one DB +A is going to dramatically improve the performance.
-Mikeal
On Thu, Jul 1, 2010 at 3:00 PM, Mikeal Rogers mikeal.rog...@gmail.comwrote:
And this is the same test
Registration is now open for CouchCamp.
http://www.couch.io/couchcamp
Anyone who is in the THANKS file gets a 300$ discount, just email me
directly and I'll get you a code to use.
-Mikeal
I'm working on blog post about CouchDB clients for different languages
and I was hoping to get some help from the crowd on this one.
What CouchDB clients are available for each language?
What ones are good and well supported?
Which ones are just plain aweful?
Which languages/platforms just have
I just want to kick the tires on this before we start locking things up for 1.0.
Do we think we can get this in?
-Mikeal
On Tue, May 25, 2010 at 11:24 PM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Wed, May 26, 2010 at 01:36, Mikeal Rogers mikeal.rog...@gmail.com wrote:
I'd like to propose
I'm thrilled to announce that Stuart Langridge will be speaking at CouchCamp.
http://www.couch.io/couchcamp
Stuart is a hacker, author, and speaker living in the UK. He writes
books about JavaScript and talks to people about Ubuntu, and also
works for Canonical creating online services and
This is great.
Is there a way we might be able to get the CouchDB DEBUG output in to
the test dbs? That would go a long way towards helping us debug
reports that we get.
-Mikeal
On Mon, Jun 7, 2010 at 5:42 PM, Noah Slater nsla...@tumbolia.org wrote:
On 7 Jun 2010, at 18:14, J Chris Anderson
I'm privileged to announce an upcoming event we've put together for
CouchDB developers and users, CouchCamp!
http://www.couch.io/couchcamp
All of the details are on the site, registration will open soon, and
we'll continue to announce invited speakers for the next week via
Twitter. You can sign
Hiya dev list,
Earlier today I sent out an email about CouchCamp which we're doing on
September 8th -10th.
Couchio will also be hosting CouchHack on September 6th and 7th in our
Oakland offices. It'll just be a bunch of CouchDB developers sitting
around writing some code. No registration free,
Couch you post this as a patch of push it to branch on github or something?
On Mon, May 17, 2010 at 6:30 AM, mickael.bai...@free.fr wrote:
Hello Couchers,
for 1 month now I'm coding a new futon page : the goal is to ease the
developper of CouchDB views/lists/shows through Futon web
.
-Mikeal
On Tue, May 18, 2010 at 4:06 PM, Jan Lehnardt j...@apache.org wrote:
Dear Mikeal,
On 19 May 2010, at 00:55, Mikeal Rogers wrote:
Couch you post this as a patch of push it to branch on github or something?
Can you kindly send me a week's supply of what you've been consuming today
...@gmail.com wrote:
On May 18, 2010, at 4:09 PM, Mikeal Rogers wrote:
haha!
s/of/or/g
I actually do have this running from this zip, which I had to wait 60
seconds staring at a counter in order to download :)
But i think most people won't be doing that and want a patch or a
something
correct, this is now the ddoc, so if you attach templates as attributes to
your ddoc you can pull them out with something like:
this.templates['mytemplate.mustache'].
The way you were using this previously is a very very bad idea because there
are no guarantees that you won't at some point in
If the point is to replace the wiki then it needs to be *easier* than
the wiki for people who aren't committers.
The big advantage to markdown is that you can parse it to HTML in a
strict mode that will escape any HTML in the original text makeing it
a lot easier to take contributions from people
I think for social and community reasons requiring the same process
for doc changes as we do for code contributions is a huge barrier to
documentation contributions.
On Sat, Mar 6, 2010 at 4:11 PM, Noah Slater nsla...@tumbolia.org wrote:
Oh, technically we could. The issue here is social and
nsla...@tumbolia.org wrote:
Why? It's not about process per se, it's about providence and copyright
assurances.
On 7 Mar 2010, at 00:24, Mikeal Rogers wrote:
I think for social and community reasons requiring the same process
for doc changes as we do for code contributions is a huge barrier
I'm using the new vhost + rewrite stuff and really loving it but I
just hit a snag.
I've got something like
[vhost]
domain.com /dbname/_design/app/_rewrite
Since all calls to the vhost are sent to the rewriter I can't access
the document API and I can't rebuild the document API in the rewrite
Sorry, gmail decided to send that too early.
A proposed fix would be.
Making to
Making to references that begin with / absolute to the entire
CouchDB and rules that do not begin with / relative to the ddoc the
way they are now.
Also, introduce a new variable :dbname which refers to the
dgoodlad you can use '../' to refer to the path above the design
doc, and so on
Problem solved :)
On Sat, Mar 6, 2010 at 9:26 PM, Mikeal Rogers mikeal.rog...@gmail.com wrote:
Sorry, gmail decided to send that too early.
A proposed fix would be.
Making to
Making to references that begin
I'm +1 on dogfooding a couchapp doc site.
Last week Greg Stein mentioned something about a space that you can
get at apache.
Basically you get a box or VM or something that is part of apache
infrastructure but the apache infra people don't maintain it, the
people in your project do, so you can
A better way to do that kind of cache invalidation would be to use _changes.
Cache the sequence number along with the objects, then do a new
_changes request with since=seq and then keep it open continuously so
you can use the push notifications to update objects on the page and
in the browser in
The etag is for the entire query, I think he wants to cache on an doc
by doc basis for all the docs that were returned for the query. But
this does remind me that you'll still need to check the etag and the
query again if there are *new* documents in the query.
-Mikeal
On Wed, Feb 17, 2010 at
I think a better wiki is a good idea.
That said, I don't consider MediaWiki a better wiki.
-Mikeal
On Sat, Jan 23, 2010 at 12:29 AM, Brian Candler b.cand...@pobox.com wrote:
On Fri, Jan 22, 2010 at 09:30:53PM -0800, Chris Anderson wrote:
Should we move onto a more standard wiki software?
I have been putting together some stuff that seems pertinent to this
discussion.
I'm working on a performance suite that tests a variety of concurrent
performance scenarios.
I have the client code written but I'm still working on the automated
build/test code. Once that is finished I plan to do
The issue seems to be that some stuff was broken in Spidermonkey that didn't
effect Firefox or Thunderbird and the fixes for that stuff is still being
back ported.
http://code.google.com/p/js18/wiki/BugzillaStatus
-Mikeal
On Thu, Nov 19, 2009 at 6:08 AM, Jan Lehnardt j...@apache.org wrote:
CouchDB currently uses Spidermonkey 1.7 as it's javascript interpreter.
1.7 was released in 2007. 1.8.5 is the current version number used in trunk,
anything 1.8.1 should have tracing support and should be much improved in
terms of performance.
1.8.x also has a lot of new JavaScript features
Does anyone know the status of native JSON support on other browsers,
and how 'undefined' is handled?
Everyone I'm aware of (IE Safari) that are doing nativeJSON are following
the ECMA standard which handles undefined the same way Mozilla nativeJSON
does.
-Mikeal
versions of
that API.
-Mikeal
On Wed, Nov 18, 2009 at 4:01 PM, Paul Davis paul.joseph.da...@gmail.comwrote:
On Wed, Nov 18, 2009 at 6:34 PM, Mikeal Rogers mikeal.rog...@gmail.com
wrote:
The same could be said of your Python view server vs. what's in
couchdb-python though, right? Or what
If we don't require a certain feature set in javascript, like if we want to
go lowest common denominator and make sure views are usable even in a
pure-javascript CouchDB in Internet Explorer then it would be pertinent to
add some additional features to the default javascript view server API
Back to the multiple JS version question though, its not quite the
same thing. jQuery is there to gloss over differences in
implementation. It is *not* for differences in the language. For
example, jQuery can paper of the differences between event names but
it can't implement iterators.
Affects Versions: 0.10
Environment: Mac OS 10.6 with icu4c-4.3.2
aclocal --version == 1.10
autoconfig --version == 2.61
Reporter: Mikeal Rogers
Priority: Minor
Fix For: 0.11
For some unknown reason `icu-config --version` outputs -n 4.3.2 when run from
If you did the POST with XHR you could embed the redirect logic in the
client code rather than in the server.
-Mikeal
On Wed, Oct 14, 2009 at 11:12 AM, Sven Helmberger sven.helmber...@gmx.dewrote:
Chris Anderson schrieb:
On Wed, Oct 14, 2009 at 10:18 AM, Sven Helmberger
Haha, I completely misread the subject. s/without/with.
-Mikeal
On Wed, Oct 14, 2009 at 11:17 AM, Sven Helmberger sven.helmber...@gmx.dewrote:
Mikeal Rogers schrieb:
If you did the POST with XHR you could embed the redirect logic in the
client code rather than in the server.
-Mikeal
um
That said, using Apache SVN in an argument about providing that
paper trail prevents me from considering the issue seriously. I'm a
hacker. I hack. I judge my tools and I have judged SVN to be lacking.
I would very be very excited to see hosted git repositories for ASF
contributors and would use
A CLA is required for any contribution, even patches. An SVN
repository doesn't inherently fix this as patches can still be sent to
committers over email and then checked in. While it's true git
encourages more distributed workflows it's still the responsibility of
committers to make sure
Does anyone have an example of an HTTP client that doesn't support
changing or adding headers?
I certainly can't think of any. Limiting request methods is one thing
but not allowing you to modify headers is pretty crippling.
-Mikeal
On May 14, 2009, at May 14, 20096:29 AM, Brian Candler
On May 13, 2009, at May 13, 20099:58 AM, Jan Lehnardt wrote:
On 13 May 2009, at 18:43, Jared Scheel wrote:
Sorry for responding to my original message instead of a reply in the
thread, but I seem to be having some issues with the mailing list.
Oliver, you are right, I could use a javascript
That was against an early TraceMonkey build which is 1.9, not 1.8 .
Firefox 3 ships with 1.8 and generally uses less memory than FF2.5 so
I would hope this isn't the case.
-Mikeal
On Mar 23, 2009, at March 23, 200911:45 AM, Bradford Winfrey wrote:
If I recall, I believe Jan tried
97 matches
Mail list logo
