Couch access, ENGAGE-213, etc.

[Colin Clark]

Hi again,

On 17-Dec-09, at 1:26 PM, Antranig Basman wrote:
>>> <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.

Yeah, I see what you're saying. It's working because of the way Tomcat  
is parsing these URLs and simply ignoring path depths that go too deep.

This seems like something Yura or Justin can fix as they're  
refactoring View and Browse to support the new exhibit features.

>>> 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.

This makes sense. Honestly, I'm leaning heavily towards the option of  
refactoring jquery.couch and submitting a patch back to the Couch  
community. It's a good in with them, and a chance to get to know them  
better. I'm not surprised that the code isn't great, since we've  
encountered lots of jQuery plugin code that doesn't uphold the same  
excellent code quality standards that jQuery itself does.

Anyway, yes, let's look at the feasibility of improving  
jquery.couch.js for our needs and sharing it back with the Couch  
community.

Can you elaborate on what you're seeing in encodeOptions() and how it  
leads you towards the beginnings of a ViewParameters-like system?  
Glancing at it quickly awhile back, it struck me as somewhat  
overlapping with jQuery's own code for converting objects into URL  
query parameters.

Great thread, let's keep it going.

Colin

---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org