Note: I'm not sure why I had to patch infinit@acbfded , but in my setup (Python 3.4.1, CouchDB 1.6.1) the output stream of the query server is text, not binary. Could be the way CouchDB starts the subprocess ? Some subtle Python difference in the way it determines whether stdin is text ? Anyway it fixes it for me and hopefully doesn't break it for other, but some double check would be a good idea.

That's completely incorrect implementation. See JavaScript query server, his tests or my fork where it's done.

I don't think "completely incorrect" is an even remotely appropriated comment. As I stated, it's partial and I'm building it as I go just to fill-in the missing feature. Now, if you have a working version - which I didn't know - I'd be more than glad to just see it merged here and use it.

If there is a fundamental flaw in the way I started implementing this, a few line stating why would be helpful. I certainly don't expect it to pass the test suite you mentionned since I implemented a small subset of the ddoc feature.

@mefyl it's "incorrect" because:

1. update functions doesn't have two level function definition like views (e.g. there is no "map")
2. they should forbid GET requests in order to not let things go wrong
3. resp part need to wrap strings with {"body": ...} object

"Completely" is because it's incompatible with the way how javascript ones works and breaks common ddoc structure what will prevent you simply backport any JS couchapp to Python.

Sorry for not describing "why" in my reply.

Now, if you have a working version - which I didn't know - I'd be more than glad to just see it merged here and use it.

Well, I stopped work on it long time ago because it's done, but it unlikely be merged because of commit history policy. So it's just there for history and for others who want to implement it again (:

Thanks for the precisions !

1. True, my design docs erroneously had this map indirection, so I ended up thinking that was the CouchDB format. I'll fix it right away. The documentation isn't really rigorous/complete, so one has to do some reverse-engineering on the protocol :-|
2. Sure thing, although I would count that as an improvement, not a "bug" in a first partial implementation :)
3. Well, I partly disagree on that one: the documentation for ResponseObject states you can use json instead of body and add headers or several other useful fields, so I left it to the update handler to return {body: ...} or any other combination (the doc I added reflects this). It is true I could wrap plain strings with {body: ...} so you can just return strings while not preventing the other features. Opinion welcomed.

About the "incompatible with javascript" part, are we talking about the erroneous map key ? If so, it's definitely a mistake I'm fixing.

Understand my process here is to implement the features on the go as I can't sit down one week with specs to implement this, so it will be incremental and inferior to a full implementation for some time. Your code will certainly be of help, thanks for pointing me to it.

@kxepal I'm sorry about the commit policy. Can I somehow entice you to do a little work to get the whole thing merged again? I started on it myself once or twice, but it's quite a bit of work and I currently lack the motivation/time to clean things up. However, given that you already know how things ought to work, it seems like a somewhat clean history isn't that much work.

Otherwise, maybe we should contemplate just squashing the whole thing and making sure the end state makes sense. Let's iterate on it together?

@djc No need to sorry: it's good that you have and require commits to met high, good, standards. I respect this and eventually try to follow the same rules. The main problem is that it's very boring to reorganize 50+ commits of iterative work and hard to keep all things consistent after conflicts. Today when I look on those code again, I wish I would at least clean it and fix the style: 4 years is quite a lot of time to change the views on Python coding.

I see two ways to handle it:

• Reorganize commits to make history more or less clear and make their share right. It would be hard because there iirc there were three versions which evolved one to another: one big view.py -> server subpackage -> stateless design. In the middle new features were added while existed bugs were fixed.
• Just squash all the stuff and move important bits from commit messages into code commentaries and doc strings. Most simple way to go and it will force to pay more attention to code review, but will produce one massive commit. However, not sure if any history will be important if the code itself will be well documented.

P.S. Sorry for my initial attitude here, it seems I wasn't in good mood to be polite.

@kxepal can we just go straight to implementing the stateless design? With the policy I have in mind, the goal is not to reflect exactly the history of development. The goal is only to have commits that are understandable as a unit, that work towards the goal of the series, and ideally are easily reviewable (which implies some upper bound on size, ideally). I may not have expressed this clearly before. So what I don't like is having the extra bug-fixing commits in the history; those should be squashed into the commit that introduced the bug. Would this make it easier?

Thanks for the apology, accepted. Everyone can have a bad day!

@djc you know....I walk over the history, read the code and found that the only way to make it work and don't feel the shame about, is to cut the latest code version into consistent commits. I have the following plan in my head now:

• 1 commit to turn view.py into server subpackage
• 1 commit per design function
• 1 commit per new feature
• 1 commit per important bug fix (those which are couchdb-* )
  Sounds good for you?

I just imported viewserver branch to GitHub to make it easy estimate all the tragedy (:

No offense taken either; if your implementation is being merged, I'll stand by waiting for it. As I stated, there is still infinit@acbfded that is require for the server to work at all in my setup, so maybe just this patch should be considered ?

(also the short sha1 is a permutation of abcdef, that should make it worth keeping)

@kxepal that sounds awesome!! I'd love to get that merged.

@mefyl sorry to side-track your pull request, and sorry if your work doesn't end up being used in the project. Still, your pull request has been instrumental in landing a better view server, so I hope you're getting a good deal in the end. I bet @kxepal will look at your pull request if he has problems getting his work to pass with Python 3.

I have no pride in seeing MY code merged, if I too get a fully featured view server at no development cost, it's even better :)

This will be done as part of #286, closing.