On 13/12/2008, at 4:13 PM, Chris Anderson wrote:
On Fri, Dec 12, 2008 at 9:31 PM, Antony Blakey <[email protected]
> wrote:
On 13/12/2008, at 3:48 PM, Chris Anderson wrote:
Antony, I think you'll find that once you've written the appropriate
JavaScript tests for this feature, it'll be hard to resist adding
escaping to the Erlang db-name validation code.
Actually, the name validation would merely consist of 'not-empty'.
The gating issue is getting agreement about the on-disk structure,
because
the key change is breaking the name <=> filename equivalence
assumption.
Sure - I guess I was referring to the call sites. Replacing the now
obsolete validation function with the URL encoder seems like a good
way to implement.
I'd approach the issue at the URL encoding/decoding side of the Erlang
stack-trace, just so we can have the same name format throughout the
codebase. If the current codebase is just looking at strings like
"Ser+vices%2Fnew+-+%E2%88%9E%E0%A4%B6%E0%A4%9B%D8%BA%D8%B4%EA
%B0%A5%EA%B1%B8%E3%83%9A%E3%83%9C-lhxj+E81IP9xm+0ssUSsQ=="
then we'd know we don't have to worry about any high-byte problems.
The quoted string above is pretty close to legal under the current
ruleset.
The codebase doesn't really see those strings, it sees the decoded
name e.g. full Unicode. The HTTP layer sees the encoded value in the
URL, but that's normal for HTTP. I have used a Unicode request string
through Safari without a problem.
Those names are only generated at the point of filesystem access
within Couch, where a given { object name + purpose } has to be mapped
to a filepath for the purpose of opening/creating/deleting a file.
In any case I strongly prefer the second filesystem layout I
presented, which involves simple changes in just a few locations.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Human beings, who are almost unique in having the ability to learn
from the experience of others, are also remarkable for their apparent
disinclination to do so.
-- Douglas Adams
