incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <>
Subject Re: [BEP-0003] Request to reject /ticket/<product prefix>/<sequence ID> routes WAS: [Apache Bloodhound] Proposals/BEP-0003 modified
Date Wed, 21 Nov 2012 04:37:06 GMT
On 21.11.2012 05:08, Olemis Lang wrote:
> On 11/20/12, Gary Martin <> wrote:
>> On 20/11/12 09:24, Peter Koželj wrote:
>>> On 19 November 2012 16:45, Olemis Lang <> wrote:
>>>> On 11/19/12, Gary Martin <> wrote:
>>>>> On 19/11/12 07:04, Olemis Lang wrote:
>>>> [...]
>>>>>> On 11/19/12, Apache Bloodhound <>
> [...]
>>>>> Up until now I have been considering using 'products' as <namespace
>>>>> path> but we might want to choose something else or even consider
>>>>> whether this should be configurable. Configurability leads to some
>>>>> problems when a user chooses a path that is already taken of course.
>>>> I have a idea for this ... I'll write something on the subject later
>>>> today
>>>> .
>>> I do not see a point for having namespace configurable. It complicates
>>> things for us and gives user a chance to shoot itself in the foot.
> By default they won't , since installer will only provide default well
> known routes and they may be similar to multi-environment deployments.
> I see that statement somehow different . I'd rather say «I do not see
> a point for not having namespace configurable if that's what users
> want» .

Eh, making things configurable just for the hell of it ("because users
want that" or for whatever other foggy reason) is bad design because it
complicates your (data) model for no obvious benefit. Of course user
will want it if you tell them it's possible.

A case in point, Subversions "svn:externals" property can refer to
external entities at any depth in the working copy tree, not just in the
directory where the property is set. This sounded like a sexy idea back
in 2003 when they were designed, but in practice the number of weird
edge cases and exceptions that it generates and consequently the number
and intractability of the working-copy bugs related to that one, single
unnecessary quirk of this feature has by far outweighed the benefit that
any Subversion user may conceivably have got from it.

Another case in point, Subversion's original HTTP/DAV remote access
protocol allows the server administrator to configure just one component
of the of the DAV versioned resource URL that gives clients access to a
particular historical version of a file or directory. The result is that
clients have to discover that URL prefix from the server *for each
resource*, then cache the versioned-resource URI of each file in the
working copy (and that thing can conceivably change between two
consequent updates), making the protocol slower because it required more
trips to the server, and the working copy management more complex. Not
surprisingly, HTTPv2 does not allow that "flexibility" any longer, and
as a result it can actually make use of asynchronous pipelined HTTP

Keep it simple. Never make things configurable just because you can.
Think of the consequences. Consider how you'll design a RESTful API for
Bloodhound in the face of indeterminate URIs. Etc. ad nauseam.

-- Brane

Branko Čibej
Director of Subversion | WANdisco |

View raw message