couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <>
Subject Re: 0.9.0 Release
Date Wed, 03 Dec 2008 23:59:41 GMT

On 04/12/2008, at 9:55 AM, Chris Anderson wrote:

> On Wed, Dec 3, 2008 at 6:09 AM, Adam Kocoloski < 
> > wrote:
>> 2) The "/" in the _design doc ID is confusing.  I know it's just a  
>> document
>> in a flat namespace like any other and therefore I need to URL- 
>> encode the
>> "/", but to a new user playing with Futon it can look like CouchDB  
>> is really
>> using a nested namespace.  I think there could be an alternative  
>> (either
>> promoting _design/ to a proper resource or maybe using a different  
>> delimiter
>> in the design doc ID) that would be "less surprising".  At least I  
>> think
>> it's worth another discussion before the beta.
> I think the solution might be wrapped up in getting paths to
> attachments to legally work like:
> GET /db/docid/attachment/name/has/slashes.jpg
> Even if we don't provide the intermediate items as resources, letting
> slashes work like this will go a long way to simplifying file-system
> synching.
> A solution that is rather blunt: just RUI encode everything in the
> attachment part of the path before searching the docs attachments.
> We'd have to compromise and say that / in docid's must be send as %2F.
> Which would leave the design docs back at the place where they were
> before they magically encoded their slashes. (or we could have an even
> more special special rule for design docs.)
> Oh someone, please make it easy! (and correct)

Someone please make it absolutely, 100%, correct.

Special names, special paths, sometimes encoding, sometimes not. Such  
magic is evil because it always comes back to bite your arse.

Hierarchic id's being confused with/mapped to the URL hierarchy is a  
bad idea.

IMO design documents should use a different character for the  
separator. And ignoring for a moment the meta-circular problem, the  
view of all design documents should be just that - a view. Even if it  
is an Couch-internal view, it should still be presented as such (ala  
schema information in RDBs).

As far as hierarchic attachments are concerned, IMO it would be useful  
for a 'directory' request to return a json document listing the  
immediate children, in the same format as on the owning document.

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

View raw message