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
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
