On 31/12/2008, at 11:07 PM, Robert Dionne wrote:
I understand the issue. I noted the use of _id versus id myself and
wasn't that put off by it, just seemed a quirk of the implementation.
Implementations quirks shouldn't be materialized in the API. They're a
red flag that says "this wasn't designed", and IMO are always regretted.
But these aren't implementation quirks - Damien did think about this
issue, I just think he weighted the competing issues wrongly.
I realize you've likely written a lot of code a this point and have
run into reuse issues. It's not unusual to have different names for
the same thing if the context is different.
It's not unusual for APIs to be not as good as they could be,
sometimes because of lack of thought, sometimes lack of knowledge.
I guess one either regards the fundamental nature of name identity to
be important, or not. No value judgement intended.
5. Use a '_meta' wrapper for the metadata. I don't see any
technical cons, and IMO is by far the cleanest model. Name identity
is preserved, it's arbitrarily extensible without scalability
concerns, and is structural rather than lexical.
It is clearly cleaner and has it's advantages, however I have to
agree with an earlier poster; "Putting them in a _meta group might
encourage aggregation and manipulation of the bookkeeping metadata
separately from the document, which to me sounds like a recipe for
trouble."
It might encourage, or might not. Orthogonally, however, what's wrong
with treating and manipulating metadata separately from the document?
To give a concrete example, I manipulate _id and _rev separately from
the 'rest' of the document now, because _id + _rev uniquely identify
an immutable value, and that value (the document) can be cached, keyed
on _id + _rev, with no concern about cache invalidation. It's
fantastic. Chris Anderson was surprised that I would want _id and _rev
in a view that doesn't supply the document, and then allow my users to
write to the document on that basis. That's an example of where
someone (with much more Couch expertise than me) was guided by their
own context and uses, to not see a particular way of using the system.
That's no disrespect to Chris, but rather an indication that the
application of general principals are a better way to do API design
than the extrapolation of one's own experience or use cases. My goal
is a design methodology driven as much as possible by an algebra of
design principles. This has been done before in e.g. in programming
language design, of which API design is a form. Sorry, pet topic of
mine :/
IMO there are good reasons to allow the document and it's metadata to
be separated cleanly, and even if I *couldn't* think of any use cases,
the idea that one should discourage it without having rock solid
technical reasons for saying that it *must* not be done, I think is
wrong.
This would be a more complex design than the current use of the
underscore at the top level of documents and would definitely
encourage a quite different implementation. I don't know the
internals enough yet to comment on this. The code there to date is
remarkably terse for what it does but this may just reflect the use
of Erlang.
Even if it's a bit more work for the implementation, I think the
cleanliness that results is worth it. An implementation is built once,
and used many times, and it's the uses/users of the system that should
have priority.
BTW: That's not a criticism of the gatekeepers - I know they agree
with this principle, because they've agreed to accept a more
complicated file system layout implementation in order that database
and design document/view names can be arbitrary.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
The fact that an opinion has been widely held is no evidence whatever
that it is not utterly absurd.
-- Bertrand Russell
