Couch access, ENGAGE-213, etc.

[Antranig Basman]

Colin Clark wrote:
> Hey Antranig,
> 
> On 15-Dec-09, at 4:16 AM, Antranig Basman wrote:
> 
>> Actually although everything looks hot, it is in fact not - we have a 
>> recurrence of the "excessive path depth" syndrome in the mounted URLs 
>> which will mean that the standalone version of Engage is almost 
>> certainly broken again. Here is a standard link from the head of the 
>> page below:
>>
>> <link type="text/css" rel="stylesheet" 
>> href="../../../../fluid-infusion/src/webapp/framework/fss/css/fss-layout.css"></link> 
>>
>>
>> As you can see it has grown four up-segments where only two are 
>> required. I've filed ENGAGE-216 and also want to draw attention to 
>> Justin's ENGAGE-193.
> 
> Can you elaborate on ENGAGE-216? You say that the "standalone version of 
> Engage is almost certainly broken again," but the daily build link I 
> sent along earlier is indeed the standalone version of Engage. It seems 
> to be working just fine. The Eclpise build is similarly working.

OK, then I should have said the standalone version is *certainly* broken
since it is from that markup that I pasted the text above with the
broken recursion depth. This probably means that *all* configurations
are currently broken and only appearing to work through being given a
path depth greater than that in any current URL mount.

>> In this patch are also the beginnings of a rudimentary Couch "API" 
>> similar to some of Joan's work in the scratchpad, including 
>> demonstration of how to issue an HTTP HEAD request to retrieve a 
>> document revision number from etags supplied by Couch. We should talk 
>> about these directions further at the tech meeting on Thursday.
> 
> Tell us more about how this new code relates to the couch.js and 
> jquery.couch.js utilities that ship directly with Couch?
> 
> http://titan.atrc.utoronto.ca:5984/_utils/script/couch.js
> http://titan.atrc.utoronto.ca:5984/_utils/script/jquery.couch.js

Well, looking over the code in these files, one important difference
seems to be that the Couch shipping utils appear to be entirely unsafe
for use on the server. couch.js for example uses a single globally
shared cached array of document uuids which will become corrupted by
multi-threaded access. However it does show an interesting strategy for
assigning the document id - it appears Couch does not need to see that a
document revision submitted agrees with a particular one in the
database, but only requires that it is "recent enough" - see the
workflow leading from "this.save" to newUuuids in couch.js. We will need
something like this cache, but it will need to be implemented differently.

The JQuery couch code on the other hand *does* appear to be thread-safe,
at least from a general eyeball (hard to *prove* that code is
thread-safe) but on the other hand does not make any attempt to help the
issue of a PUT to an already existing document - in particular I don't
see any functionality to quickly acquire the version info for an
existing document using for example the HEAD/getResponseHeader combo
that I had written in my version. The JQuery plugin is unusually
repetitive for code connected to the JQuery base - perhaps we can ship a
condensed version back to them :P
I see the beginnings of a "ViewParameters" like system in the
"encodeOptions" call at the base of jquery.couch.js ... in general, I
suggest we use these two files as inspiration and perhaps even API
contract but perhaps not use them directly. The JQuery one at least
could be cleaned up I suppose, by being given docs and a code sweeping.

> It's clear that, for the low-level database access, we'll want as little 
> of our own code as possible--either of these seem to be a suitable 
> alternative to Joan's database.js. At the high level, you and Michelle 
> and I have chatted about some exciting framework supports for data 
> access that I still need to document in the wiki. Expect more in the new 
> year for sure.