exactly :)
On Jan 4, 2009, at 11:35 AM, Michael Fellinger wrote:
On Fri, Jan 2, 2009 at 9:30 PM, Robert Dionne <[email protected]>
wrote:
When it comes to design I think there are always tradeoffs. This is
where
intuition and experience count. In my opinion separating metadata
from the
user's data is a more complex approach. It creates two parts to the
document, they have to be handled separately and it creates the
need for two
kinds of API calls for the two types of data. It seems like a good
approach, however it's very easy to look at an existing
implementation and
see how things "ought" to be done.
The current implementation has a nice simplicity to it that I would
not
readily advocate changing. My first impression is that it reminded
me of
Berkeley DB on steroids. The convention governing the use of the
_id is not
that hard to deal with and it doesn't prevent one from handling
JSON docs
that come from elsewhere. It seems that converting data from one
database
system to another always involves some transformation.
For what it's worth, I'd love to see a separation of data and data
about data, and I'd also like to propose a change to map functions:
function(doc, meta){ emit(doc.title, [meta.id, meta.ref]); }
function(doc){ emit(doc.title); }
That way people who are complaining about having to type doc.doc.title
can have their peace of mind as well.
I might see the whole issue very limited, but it makes absolutely the
most sense to me, everybody can stop worrying about which data is
allowed in the data part and the metadata can grow in any direction.
Nobody is annoyed by prefixing _ anymore (symetric API) and there is
little technical need anymore for validating documents (as long as
they can be serialized to valid JSON) before putting them into the db.
^ manveru
This discussion reminds me of Perlis' epigram(#15) that everything
should be
built top down, except the first time.
On Jan 2, 2009, at 12:33 AM, Antony Blakey wrote:
On 02/01/2009, at 2:17 PM, Noah Slater wrote:
I appreciate you're frustrated with the current situation Antony,
but I
think
it's unfair for you to be claiming any kind of consensus without
a vote.
That post wasn't meant to be a criticism. Apologies if it felt
like it
was.
There isn't a clear consensus in this thread, which to my mind
reflects
the fact that there are trade-offs that don't have objective
evaluation
measures.
I fully support the idea that a product should reflect the vision
and
opinion of a very small group. Abstracting from my preference for
a more
robustly theoretical approach to API desig, the holistically best
result is
likely to arise from this model. So I don't e.g. mean 'gatekeeper'
in a
negative way.
I would
be interested in seeing a patch, explanation, and vote. I've
already
expressed
my agreement with many of the points you've raised, and I'm not
the only
one.
I was only referring to a lack of expressed support for a fully
reflexive
model.
It's never been clear to me that there is a process for voting - the
decision making process within the commit group seems opaque.
It's pretty pointless for us to keep sending emails over proposed
changes
to the
code without actually seeing the changes.
I think a change to the API could be decided without reference to
the code
implementing that change. In fact, IMO the API *should* be
considered
separately from the code implementing that change. Otherwise APIs
will tend
to be decided not on the basis of design, but on the amount of
effort some
person is prepared to spend to demonstrate it, and hence code
inertia, often
resulting in expedient solutions. This means that good, but
expensive ideas,
can be lost.
The models under discussion have evolved from simple name identity
by
using '_id' and '_rev' everywhere, to a '_meta' wrapper, to Geir's
fully
reflexive model.
So I'd prefer to get buy-in to a model or principles, at which point
anyone could implement it. That's what I tried to do with the
change to the
FS layout to support i18n, the committable implementation of which
is my
focus right now.
