Notes on Exportable Addresses

We want a way to identify items and collections through a name and address scheme.

Use Cases

• remote browsing
• access via Web browser

• WebDAV

  repository access protocol

A primary use case will be remote browsing from one Chandler to another. The user should be able to provide the name and address of an item, collection, or view and browse to it in a manner similar to the way a Web browser uses a URL to access a Web page.

Another important future (not committed) use case involves the actual use of a Web browser to access Chandler repository data. This presumes, among other things, something like an Apache server bundled in Chandler.

Finally, the naming and addressing scheme is important to

WebDAV

-based protocol for repository access, as Lisa can explain.

Name and Address Syntax

Schematically, we might have a URL with three parts: a protocol identifier (e.g. chandler:// as opposed to http://), an identifier for a repository or replica set (which could look like lisa@o11n.org but doesn't have to), and either a path or just a name (this is a big unresolved issue, see below).

A given data element can be accessed by more than one name and address. Chandler makes this easy and it's a good thing.

One bridging insight is to always to use Chandler's collections as the basis for aggregation of data into publicly accessible units. Or, put another way, if we choose to expose a hierarchy, we should use Chandler's mechanisms to do so, which may drive a requirement in the data model to support collections of collections.

Requirement: Minimize 404 (not found) type errors

One of Brian's main requirements is that we minimize "404"-type errors. Names should be able to be changed without breaking things. There are a number of ways to accomplish this, depending on how much trouble we want to go to.

If the name of a collection is used to form the URL, and then I rename the collection, what happens to URL's which use the old name? The thing we want to avoid is a "404: not found" error. If we made the repository remember name changes it could send back a useful message akin to getting a page redirection message on the Web.

Even if an item or collection is deleted, this could conceivably be remembered, so that a URL request to access it by name returns "item has been deleted" as opposed to "not found".

Issue: Flat vs. hierarchical name spaces

It's not clear to me that restricting to a flat space (a UUID-based space) wins us anything, but Brian may have good arguments otherwise. We will address this Thursday.

I like the idea of enabling collections to contain other collections, and then forming the namespace based on choices about which collections (including collections of collections) to be given public addresses.

Open Issue: What is the canonical name space?

On the above proposal, this is isomorphic to asking what are the default collections Chandler comes with and what rights do developers have to create and expose new collections.

Issue: Editing a URL by deleting terminal path segment(s)

If the URL is - chandler://joe@foo.com/email/inbox/337 and the user edits it to be chandler://joe@foo.com/email/inbox, what should happen?

It is NOT a requirement, in my view, that this return any data. Yes, sometimes people try this, but it's not an expectation which is widely supported, nor do I think we should.

Other issues

• detail: need to transform names to avoid nasty characters when we make a URL

Notes on "Remoting"

Andi has been talking in terms of providing a uniform interface for programmer's to access Chandler items, regardless of whether they are stored on the local repository or remotely. This matters in the case of implementing remote browsing.

Lisa has been advancing the idea that trying to access remote data as though it were local is a suspect practice and has circulated a paper about it.

It would seem there is a conflict, but it is, at a minimum I think it's less than it might initially appear, or perhaps ultimately non-existent.

Andi sent around an email in response, which if I understand the gist, significantly narrows the scope of what he means by "accessing remote data" in that he's focused entirely on a uniform interface to access an entire "item cloud" not on enabling the execution of arbitrary methods on remote objects, which I assume he agree is or could be problematic.

More to come on this, no doubt.

Are Simultaneous Efforts Duplicative or Synergistic

Andi has been focusing on the issue of how you package up stuff (the "item cloud") which is distributed in a repository for purposes of sending it over the wire in the context of our Chandler-to-Chandler sharing features. He's not focusing on issues of general and robust ways sending collections of items over a wire.

Conversely, Lisa (and Stuart) are focusing on the "other half" of the problem, which is assuming there is way to actually extract the right things from the repository, how is it best packaged up and actually sent (in a

WebDAV

-like way) once you have it from the repository for sending things over the wire.

So while it sometimes seems like there are parallel, hence duplicative efforts, the process seems to have the character of building the transcontinental railroad. You've got track being laid in two places. The idea is to make a unified set of tracks in the end, and what matters is the two meet somewhere near each other to make driving the golden spike easier.

WebDAV

and neutral interoperability formats

On the subject of about a repository access protocol that can be used by non-Chandler as well as Chandler software and the role of

WebDAV

, a little light bulb went off over my head yesterday when I talked to Lisa.

The approach

WebDAV

takes is to think of content being sent (as a Resource) that has a particular set of properties and property values. So, to send an event, you have to know what the properties are of the event.

So I naively said, well hasn't this already been defined by iCalendar. I learned that iCalendar and many other standardized data formats are defined in terms of a file format, whereas what

WebDAV

wants is an XML-based metadata structure for the semantics. So there has to be a mapping between the two that deals with various syntactical issues and conventions. It can't be completely automatic. That important detail aside, the bigger light bulb was this.

Why not use the

WebDAV

set of properties etc. to be a neutral interoperability format which Chandler supports. The content model as relates to "event" inside Chandler would be "marked up" with (that is, extended to include) a mapping between how this particular version of the Chandler content model represents events and some public interoperability format we choose to support. (Conversely, there would be something in the content model about what public interoperability formats were understood for purposes of importing data into Chandler.) That way, we have a way to emit calendar event info according to a standard public format. We could even use this to migrate data between two different versions of the Chandler content model. the public interoperability formats could evolve in a way which was responsive to the changing conditions in the world-at-large while the Chandler content model could evolve subject to how we want to move the product forward. The content model mapping the use of WebDAV would provide the coordination mechanism. Well, it's an idea. This may be old hat to people who are used to thinking about such things, but it was an eye-opener to me.

-- MitchKapor - 21 Apr 2004

---

See also

Warning: Can't find topic Trash.PagesAboutAddressing