You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Noah Slater <ns...@apache.org> on 2009/01/02 04:47:56 UTC
Re: Changing rev to _rev in view results (Was: Re: newbie question
#1)
On Fri, Jan 02, 2009 at 09:15:21AM +1030, Antony Blakey wrote:
> No. The primary reason is "why change - the current mechanism has worked for a
> year". Damien (project lead) doesn't regard change as necessary, and a
> significant change to support top-level reflexivity (which is your primary
> thrust) doesn't have support from the other gatekeepers. There is some support
> for name identity, although I suspect not enough to prompt a change.
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. 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.
It's pretty pointless for us to keep sending emails over proposed changes to the
code without actually seeing the changes. So, in the tradition of the Linux
kernel, show the code and let's have a vote!
--
Noah Slater, http://tumbolia.org/nslater
Re: Changing rev to _rev in view results (Was: Re: newbie question #1)
Posted by Antony Blakey <an...@gmail.com>.
On 02/01/2009, at 10:51 PM, Geir Magnusson Jr. wrote:
> But I am a little worried that if the "project lead" and
> "gatekeepers" are even *thought* by active members of the community
> to be dead-set against it that I would be wasting time.
To be blunt, and this is my impression only: I thought Damien was
strongly against changing it, and got the impression that there was
some significant degree of deferral to his opinion, understandably. It
is difficult to get a handle on the social and procedural dynamic in
this situation.
I really don't want any political/social meta-issue to get out of
hand, sorry if I lead it in that direction.
> I think it's an important issue (clearly or I wouldn't be spending
> so much vacation time discussing it), but it's not a make-or-break
> issue for me.
Ditto.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Nothing is really work unless you would rather be doing something else.
-- J. M. Barre
Re: Changing rev to _rev in view results (Was: Re: newbie question #1)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
I actually don't mind digging in and spending the time showing what I
mean with code (although the barrier here is much higher since I don't
know erlang at all...)
But I am a little worried that if the "project lead" and "gatekeepers"
are even *thought* by active members of the community to be dead-set
against it that I would be wasting time.
I think it's an important issue (clearly or I wouldn't be spending so
much vacation time discussing it), but it's not a make-or-break issue
for me.
geir
On Jan 2, 2009, at 7:17 AM, Noah Slater wrote:
> Not really, my point stands. Show the code, then we vote. :)
>
> On the other hand, consensus building can't harm either.
>
> On Fri, Jan 02, 2009 at 07:14:26AM -0500, Geir Magnusson Jr. wrote:
>> Maybe the tradition should be of an Apache project? :)
>>
>> From my limited interaction w/ the Linux kernel community, it's a
>> very
>> different beastie...
>>
>> geir
>>
>> On Jan 1, 2009, at 10:47 PM, Noah Slater wrote:
>>
>>> On Fri, Jan 02, 2009 at 09:15:21AM +1030, Antony Blakey wrote:
>>>> No. The primary reason is "why change - the current mechanism has
>>>> worked for a
>>>> year". Damien (project lead) doesn't regard change as necessary,
>>>> and
>>>> a
>>>> significant change to support top-level reflexivity (which is your
>>>> primary
>>>> thrust) doesn't have support from the other gatekeepers. There is
>>>> some support
>>>> for name identity, although I suspect not enough to prompt a
>>>> change.
>>>
>>> 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. 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.
>>>
>>> It's pretty pointless for us to keep sending emails over proposed
>>> changes to the
>>> code without actually seeing the changes. So, in the tradition of
>>> the
>>> Linux
>>> kernel, show the code and let's have a vote!
>>>
>>
>
> --
> Noah Slater, http://tumbolia.org/nslater
Re: Changing rev to _rev in view results (Was: Re: newbie question
#1)
Posted by Noah Slater <ns...@apache.org>.
Not really, my point stands. Show the code, then we vote. :)
On the other hand, consensus building can't harm either.
On Fri, Jan 02, 2009 at 07:14:26AM -0500, Geir Magnusson Jr. wrote:
> Maybe the tradition should be of an Apache project? :)
>
> From my limited interaction w/ the Linux kernel community, it's a very
> different beastie...
>
> geir
>
> On Jan 1, 2009, at 10:47 PM, Noah Slater wrote:
>
>> On Fri, Jan 02, 2009 at 09:15:21AM +1030, Antony Blakey wrote:
>>> No. The primary reason is "why change - the current mechanism has
>>> worked for a
>>> year". Damien (project lead) doesn't regard change as necessary, and
>>> a
>>> significant change to support top-level reflexivity (which is your
>>> primary
>>> thrust) doesn't have support from the other gatekeepers. There is
>>> some support
>>> for name identity, although I suspect not enough to prompt a change.
>>
>> 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. 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.
>>
>> It's pretty pointless for us to keep sending emails over proposed
>> changes to the
>> code without actually seeing the changes. So, in the tradition of the
>> Linux
>> kernel, show the code and let's have a vote!
>>
>
--
Noah Slater, http://tumbolia.org/nslater
Re: Changing rev to _rev in view results (Was: Re: newbie question #1)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Maybe the tradition should be of an Apache project? :)
From my limited interaction w/ the Linux kernel community, it's a
very different beastie...
geir
On Jan 1, 2009, at 10:47 PM, Noah Slater wrote:
> On Fri, Jan 02, 2009 at 09:15:21AM +1030, Antony Blakey wrote:
>> No. The primary reason is "why change - the current mechanism has
>> worked for a
>> year". Damien (project lead) doesn't regard change as necessary,
>> and a
>> significant change to support top-level reflexivity (which is your
>> primary
>> thrust) doesn't have support from the other gatekeepers. There is
>> some support
>> for name identity, although I suspect not enough to prompt a change.
>
> 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. 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.
>
> It's pretty pointless for us to keep sending emails over proposed
> changes to the
> code without actually seeing the changes. So, in the tradition of
> the Linux
> kernel, show the code and let's have a vote!
>
> --
> Noah Slater, http://tumbolia.org/nslater
Re: Decision making process (Re: Changing rev to _rev in view
results (Was: Re: newbie question #1))
Posted by Noah Slater <ns...@apache.org>.
On Sat, Jan 03, 2009 at 12:27:20AM +1030, Antony Blakey wrote:
> Is this voting/decision-making process visible?
Yes, the formal decision making process is visible. However, as a group of
people who work closely together we communicate in lots of other ways, be that
public IRC, private IRC, private email, Twitter, or telephone calls. It is
important that we discuss everything official on the mailing list as per The
Apache Way, but it is a natural consequence of our working together that we
become informally aware of each other's position on various topics. Short of
refusing to discuss CouchDB "in real life," I see this as unavoidable.
> If I'm trying to effect a change, how can I judge what would get it over the
> line i.e. who objects and for what reasons?
I guess the best way would be to do a proper proposal and request a vote. This
vote wouldn't be anything official, but it would be an informal way of
soliciting definite feedback from the community and the committers.
> How do I ensure that my patch isn't stuck in development hell while the PMC
> (maybe) waits for consensus to (maybe never) emerge?
If you submitted a patch to the mailing list and requested a vote.
> If I have a change in mind, I would prefer where possible to get at
> least a majority of the PMC on side before doing (possibly a lot of)
> work.
Makes sense. I guess that's where a proper proposal would come in.
> It looks like it is only when a patch is up for approval that any real
> decision will be made i.e. I can't prompt a decision on the metadata thread
> without doing all the work, which may be pointless. That makes a proposal very
> expensive, especially if the PMC doesn't operate in a predictable fashion.
Predictable fashion?
> That in turn makes it less likely that people will contribute, and seem to be
> a strategic weakness.
I'm not sure I follow your reasoning at all.
The way I see it is that if someone suggests something and we all love it, there
is a clear consensus and we would go forward with that. The reverse is also
true. In this particular case it is clear to me that we do not have consensus. I
think part of that may be due to there being no concrete proposal, everyone
seems to be suggesting different things!
We are only at this juncture because nobody can agree on the best way
forwards. All I am saying is that maybe a proper proposal would be a nice idea,
something we can all say "+1" on, or not as the case may be. If you asked me now
what my thoughts were on the whole topic I would tell you that I don't know,
because I'm not even sure what the agreed proposal is, let alone the agreed
consensus is.
> IMO an improvement to this process would be a mechanism to submit a proposal
> to the *PMC*, to get some definitive feedback, the contract being that I'll do
> the proposal and the implementation in return for the PMC being prepared to
> give a provisional indication that a) such work would not be in vain; or b)
> the proposal won't be pursued; or c) more work is needed, but it's not out of
> the question; and/or d) some comment about what would need to be addressed to
> move forward. All of which is to say: is the PMC reified in some way that
> doesn't involve canvassing each member individually?
This process is already in place! Heh. All anyone has to do is write up a
concrete proposal of the changes and submit it to the mailing list requesting a
vote. We can move forward from there. If there are comments about the proposal,
the sponsor could collect them and draft a new proposal. Rinse and repeat.
--
Noah Slater, http://tumbolia.org/nslater
Re: Decision making process (Re: Changing rev to _rev in view results (Was: Re: newbie question #1))
Posted by Antony Blakey <an...@gmail.com>.
On 03/01/2009, at 12:03 AM, Noah Slater wrote:
> It's worth noting that we may never make a decision, or the decision
> might take
> a long time. Looking back at the newline proposal, we never decided
> consensus
> was to reject it outright, but we never resolved it the other way
> either. One of
> us could move to call a vote, but we all feel its better to wait for
> consensus.
Is this voting/decision-making process visible? If I'm trying to
effect a change, how can I judge what would get it over the line i.e.
who objects and for what reasons? How do I ensure that my patch isn't
stuck in development hell while the PMC (maybe) waits for consensus to
(maybe never) emerge?
If I have a change in mind, I would prefer where possible to get at
least a majority of the PMC on side before doing (possibly a lot of)
work. It looks like it is only when a patch is up for approval that
any real decision will be made i.e. I can't prompt a decision on the
metadata thread without doing all the work, which may be pointless.
That makes a proposal very expensive, especially if the PMC doesn't
operate in a predictable fashion. That in turn makes it less likely
that people will contribute, and seem to be a strategic weakness.
IMO an improvement to this process would be a mechanism to submit a
proposal to the *PMC*, to get some definitive feedback, the contract
being that I'll do the proposal and the implementation in return for
the PMC being prepared to give a provisional indication that a) such
work would not be in vain; or b) the proposal won't be pursued; or c)
more work is needed, but it's not out of the question; and/or d) some
comment about what would need to be addressed to move forward. All of
which is to say: is the PMC reified in some way that doesn't involve
canvassing each member individually?
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
You can't just ask customers what they want and then try to give that
to them. By the time you get it built, they'll want something new.
-- Steve Jobs
Re: Decision making process (Re: Changing rev to _rev in view
results (Was: Re: newbie question #1))
Posted by Noah Slater <ns...@apache.org>.
On Fri, Jan 02, 2009 at 11:19:18PM +1030, Antony Blakey wrote:
> That would confirm my presumption that it's probably a waste of time pushing
> something that Damien's firmly against, as opposed to expecting to vote on it.
I'm not too sure this is a wise approach. Chris is correct in that we've opted
for following consensus in the past, but that doesn't mean that whatever Damien
says we all agree with. There's still the issue of the JSON newline which has
the committers split right down the middle!
I see that this issue can take one of three possible routes:
* the PMC decide that consensus is to reject the proposal
* the PMC decide that opinion is spit and hold an ASF style vote
* the PMC decide that consensus is to accept the proposal
The PMC comprises me, Chris, Chris, Jan, and Damien.
It's worth noting that we may never make a decision, or the decision might take
a long time. Looking back at the newline proposal, we never decided consensus
was to reject it outright, but we never resolved it the other way either. One of
us could move to call a vote, but we all feel its better to wait for consensus.
--
Noah Slater, http://tumbolia.org/nslater
Re: Decision making process (Re: Changing rev to _rev in view results (Was: Re: newbie question #1))
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 2, 2009, at 7:37 AM, Chris Anderson wrote:
> On Fri, Jan 2, 2009 at 4:16 AM, Geir Magnusson Jr. <ge...@pobox.com>
> wrote:
>>
>> On Jan 2, 2009, at 12:33 AM, Antony Blakey wrote:
>>>
>>> It's never been clear to me that there is a process for voting - the
>>> decision making process within the commit group seems opaque.
>>
>> How can that be? I assume that all decisions are made in public on
>> the dev@
>> mailing list.
>>
>
> The committers have a history of deferring to Damien (especially on
> deeply technical matters like the document identity model). It's fair
> to say that most of what we do is bug fixes and the like. When we have
> a new feature or module under development, we like to run the code by
> Damien before we commit it. He understands CouchDB inside and out, and
> he's pretty good at seeing how an API detail or caching property will
> effect the big picture of how people use CouchDB.
That's perfectly reasonable if it's on the dev@ list.
>
>
> There have been votes on the dev list before, but they are rare
> because we so often move with consensus.
That's also perfectly reasonable, and in fact, how I personally like
to participate - it seems that if it comes down to a vote, the
consensus mode has failed.
geir
>
>
> --
> Chris Anderson
> http://jchris.mfdz.com
Re: Changing rev to _rev in view results (Was: Re: newbie question #1)
Posted by "ara.t.howard" <ar...@gmail.com>.
On Jan 4, 2009, at 9:35 AM, Michael Fellinger wrote:
> 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
i think those of us who have maintained a lot of code ourselves see
the wisdom in this. having rules that are 100% consistent lifts a
massive mental weight for anyone connected to the code.
keys.each do |key|
unless key =~ %r/^_/
...
just gives me hives to think about.
a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama
Re: Decision making process (Re: Changing rev to _rev in view results (Was: Re: newbie question #1))
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 2, 2009, at 7:49 AM, Antony Blakey wrote:
>
> On 02/01/2009, at 11:07 PM, Chris Anderson wrote:
>
>> On Fri, Jan 2, 2009 at 4:16 AM, Geir Magnusson Jr. <ge...@pobox.com>
>> wrote:
>>>
>>> On Jan 2, 2009, at 12:33 AM, Antony Blakey wrote:
>>>>
>>>> It's never been clear to me that there is a process for voting -
>>>> the
>>>> decision making process within the commit group seems opaque.
>>>
>>> How can that be? I assume that all decisions are made in public
>>> on the dev@
>>> mailing list.
>>>
>>
>> The committers have a history of deferring to Damien (especially on
>> deeply technical matters like the document identity model). It's fair
>> to say that most of what we do is bug fixes and the like. When we
>> have
>> a new feature or module under development, we like to run the code by
>> Damien before we commit it. He understands CouchDB inside and out,
>> and
>> he's pretty good at seeing how an API detail or caching property will
>> effect the big picture of how people use CouchDB.
>
> That would confirm my presumption that it's probably a waste of time
> pushing something that Damien's firmly against, as opposed to
> expecting to vote on it.
That would be the case of any committer - anyone can veto a code
change, including one by Damien (Technically it's a PMC member, but
some communities include all committers in this, which IMO is a good
way)
However, the fact that people defer to Damien is perfectly
reasonable. (But remember the goal of an ASF community - you want to
make it strong enough that the original founders/motivators can step
back)
>
>
>> There have been votes on the dev list before, but they are rare
>> because we so often move with consensus.
>
> I'm merely curious bout this, but now that Couch is formally an
> Apache project, is there some Apace mandated consensus-driven
> decision making approach, or do they accept whatever model comes in
> - I'm wondering if the ASF brand might 'mean' something in that
> sense. And I've just noticed that Geir is on the ASF board - he
> should know if anyone does!
I'm not here as anything but an interested user that knows something
about the ASF, and I see in a followup that you found something on the
website :) All is well.
geir
Re: Decision making process (Re: Changing rev to _rev in view results (Was: Re: newbie question #1))
Posted by Antony Blakey <an...@gmail.com>.
On 02/01/2009, at 11:19 PM, Antony Blakey wrote:
> I'm merely curious bout this, but now that Couch is formally an
> Apache project, is there some Apace mandated consensus-driven
> decision making approach, or do they accept whatever model comes in
> - I'm wondering if the ASF brand might 'mean' something in that
> sense. And I've just noticed that Geir is on the ASF board - he
> should know if anyone does!
Ahh yes, I should have read the Apache site :/ I'll slap my own wrist.
Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
Reflecting on W.H. Auden's contemplation of 'necessary murders' in the
Spanish Civil War, George Orwell wrote that such amorality was only
really possible, 'if you are the kind of person who is always
somewhere else when the trigger is pulled'.
-- John Birmingham, "Appeasing Jakarta"
Re: Decision making process (Re: Changing rev to _rev in view results (Was: Re: newbie question #1))
Posted by Antony Blakey <an...@gmail.com>.
On 02/01/2009, at 11:07 PM, Chris Anderson wrote:
> On Fri, Jan 2, 2009 at 4:16 AM, Geir Magnusson Jr. <ge...@pobox.com>
> wrote:
>>
>> On Jan 2, 2009, at 12:33 AM, Antony Blakey wrote:
>>>
>>> It's never been clear to me that there is a process for voting - the
>>> decision making process within the commit group seems opaque.
>>
>> How can that be? I assume that all decisions are made in public on
>> the dev@
>> mailing list.
>>
>
> The committers have a history of deferring to Damien (especially on
> deeply technical matters like the document identity model). It's fair
> to say that most of what we do is bug fixes and the like. When we have
> a new feature or module under development, we like to run the code by
> Damien before we commit it. He understands CouchDB inside and out, and
> he's pretty good at seeing how an API detail or caching property will
> effect the big picture of how people use CouchDB.
That would confirm my presumption that it's probably a waste of time
pushing something that Damien's firmly against, as opposed to
expecting to vote on it.
> There have been votes on the dev list before, but they are rare
> because we so often move with consensus.
I'm merely curious bout this, but now that Couch is formally an Apache
project, is there some Apace mandated consensus-driven decision making
approach, or do they accept whatever model comes in - I'm wondering if
the ASF brand might 'mean' something in that sense. And I've just
noticed that Geir is on the ASF board - he should know if anyone does!
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
The intuitive mind is a sacred gift and the rational mind is a
faithful servant. We have created a society that honours the servant
and has forgotten the gift.
-- Albert Einstein
Re: Decision making process (Re: Changing rev to _rev in view results (Was: Re: newbie question #1))
Posted by Chris Anderson <jc...@gmail.com>.
On Fri, Jan 2, 2009 at 4:16 AM, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> On Jan 2, 2009, at 12:33 AM, Antony Blakey wrote:
>>
>> It's never been clear to me that there is a process for voting - the
>> decision making process within the commit group seems opaque.
>
> How can that be? I assume that all decisions are made in public on the dev@
> mailing list.
>
The committers have a history of deferring to Damien (especially on
deeply technical matters like the document identity model). It's fair
to say that most of what we do is bug fixes and the like. When we have
a new feature or module under development, we like to run the code by
Damien before we commit it. He understands CouchDB inside and out, and
he's pretty good at seeing how an API detail or caching property will
effect the big picture of how people use CouchDB.
There have been votes on the dev list before, but they are rare
because we so often move with consensus.
--
Chris Anderson
http://jchris.mfdz.com
Re: Changing rev to _rev in view results (Was: Re: newbie question #1)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
exactly :)
On Jan 4, 2009, at 11:35 AM, Michael Fellinger wrote:
> On Fri, Jan 2, 2009 at 9:30 PM, Robert Dionne <bo...@gmail.com>
> 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.
Re: Changing rev to _rev in view results (Was: Re: newbie question #1)
Posted by Michael Fellinger <m....@gmail.com>.
On Fri, Jan 2, 2009 at 9:30 PM, Robert Dionne <bo...@gmail.com> 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.
Re: Changing rev to _rev in view results (Was: Re: newbie question
#1)
Posted by Noah Slater <ns...@apache.org>.
On Fri, Jan 02, 2009 at 04:03:50PM +1030, Antony Blakey wrote:
> It's never been clear to me that there is a process for voting - the decision
> making process within the commit group seems opaque.
If a patch was submitted, and it was in question, we could have a standard ASF
vote to decide if we wanted to accept it or not.
> 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.
This implies that expedient solutions are necessarily bad. I actually think
there is a trade-off between conceptually good ideas, and practically good
ideas. One of the things that separates those is working code! That is to say,
it's easy to come up with ideas, but harder to execute them -- and I think both
of those factors are important when you're discussing the way forward.
--
Noah Slater, http://tumbolia.org/nslater
Decision making process (Re: Changing rev to _rev in view results (Was: Re: newbie question #1))
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 2, 2009, at 12:33 AM, Antony Blakey wrote:
>
> It's never been clear to me that there is a process for voting - the
> decision making process within the commit group seems opaque.
How can that be? I assume that all decisions are made in public on
the dev@ mailing list.
geir
Re: Changing rev to _rev in view results (Was: Re: newbie question #1)
Posted by Robert Dionne <bo...@gmail.com>.
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.
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.
>
> Antony Blakey
> -------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
>
> The intuitive mind is a sacred gift and the rational mind is a
> faithful servant. We have created a society that honours the
> servant and has forgotten the gift.
> -- Albert Einstein
>
>
Re: Changing rev to _rev in view results (Was: Re: newbie question #1)
Posted by Antony Blakey <an...@gmail.com>.
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.
Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787
The intuitive mind is a sacred gift and the rational mind is a
faithful servant. We have created a society that honours the servant
and has forgotten the gift.
-- Albert Einstein