From the Arc tutorial, line 372

arc> (is 'a 'a)
t

(for those who don’t get the joke, don’t worry, it wasn’t that funny. Neither was Ayn Rand.

Paul Graham:

Tables are the lists of html. The W3C doesn’t like you to use tables to do more than display tabular data because then it’s unclear what a table cell means. But this sort of ambiguity is not always an error.

Zed Shaw:

I may never do another CSS only layout again. I’m starting to wonder how … we got sucked into that crap, especially if the only way to really get a good looking layout with CSS and div tags is with mountains of stylesheets, html, and sometimes some damn javascript.

I’m not kidding about the javascript. I’ve seen people desperately trying to force their square-peg 3 column layout through the CSS round hole resort to javascript tricks to force the columns in the right spots.…

It’s not gauche to do what’s easiest and nobody’s going run you out of Designer Town (population 100) with sharpened pitchforks and blazing torches.

Insincere apologies to Zed for the bowdlerization.

Arc, a long-awaited dialect of Lisp, is finally available to the public for testing. As the man says:

“Arc is still fluid and future releases are guaranteed to break all your code. In fact, it was mainly to aid the evolution of the language that we even released it.”

Graham has been influential in encouraging the curious to try out a lisp of one sort or another. Since I first read his articles about Common Lisp and began tracking the infuriatingly undocumented progress of Arc, several new lisps have appeared. Here is wealth, and may Arc enrichen us further.

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!

While CouchDB currently has no authentication or authorization facilities, a general outline of the plans exists here:

http://www.couchdbwiki.com/index.php?title=Technical_Overview#Security_and_Validation

It seems databases will have admin accounts. Full stop. No baked-in facility for user accounts. Administrators have two powers:

1. manage design documents
2. create other admin accounts

The Technical Overview doesn’t say, but I assume admins can also manage all documents.

Regarding non-administrative users, as I understand the plan, CouchDB will provide a rudimentary authentication delegator that accepts a login and password. “The user credentials are input to a javascript function, and the function returns a list of [reader-names] for the user, or an error if the user credentials are wrong.” I read this as meaning that the authenticating/authorizing javascript function is determined by the developer.

Write access, called “Update Validation” in the Technical Overview, is also handled dynamically by javascript: “Both the user’s credentials and the updated document are given as inputs to the validation formula, and can be used to implement custom security models…” Developers are free to implement custom authorization models, such as “author only”, where users must be listed in an author field in the document.

Read access is granted by a simplified ACL system. A CouchDB document may have a “reader list”, which specifies a list of “reader-names”. These reader-names need not correspond to user login names, so they are effectively the equivalent of groups (i.e. you can give one or more users the same reader-name). A user’s possession of a reader-name is determined by the javascript function that authenticates user logins.

Documents without a reader list are world-readable. Documents protected by reader lists are viewable only by users who possess one of the reader-names on the list. Read protection on documents applies to view results as well: “Documents that are not allowed to be read by the user are dynamically filtered out of views, keeping the document row and extracted information invisible to non-readers.”

The Technical Overview does not address this directly, but the _all_docs view must follow the same rules. That is, all unprotected documents show up in the results for all users, but protected docs only show up for users possessing the correct reader-names. The javascript functions that bind it all together will probably need administrator privileges.

Some interesting points:

• The plans for write access allow developers to write their own authorization schemes, but the planned read access will be hard-coded to use document-based ACLs.
• By default, document names (i.e. DocIds) are 128 bit UUIDs generated by the server. Depending on the algorithm used to generate them, these could be unguessable.
• If the _all_docs view was not available, users would not be able to find any documents without knowledge of the (unguessable) DocIds.
• The authentication javascript, upon success, is supposed to return a list of reader-names, but I don’t see that anything would prevent it from returning a list of DocIds.

I think we have the germ of a capability system here, even with the inflexible reader access.

Comments? Scathing refutations?