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