Exportable vs. internal addresses

Morgen & I talked for a couple hours about addressing (and before that, parcel loading XML format, which needs addressing) and this tries to capture some of that.

When Chandler makes its repository browsable, it will have to expose external addresses for its items. Some requirements/goals:

• These exported addresses must be human-readable
• Exported addresses should be compatable with hierarchical naming addresses, e.g. HTTP, FTP, IMAP.
• It should be possible to have more than one exported address per item
• Exported addresses should not depend on the repository addressing
• Exported addresses should not depend on a parcel name
• The exported address space should be able to address parcels, kinds etc as well as content items

Use cases:

1. I want to share my Calendar via its default exportable address, as a HTTP link. I cut and paste this address and email it to people. They see something like "http://lisamachine.example.com/Chandler/Lisa/Calendars/Personal".
2. I have an IMAP synchronized mail, containing mail received through my ISP. One day I decide to share the contents of this mail folder, but I decide the URL is too long -- it's "http://lisamachine.example.com/Chandler/Lisa/Mail/myisp.account/Inbox/knitting-group". I configure a shorter alias to this folder as "http://lisamachine.example.com/Chandler/sharing/knitgroup" -- possibly simply by dragging the "knitting-group" folder to some "sharing" collection and renaming it.
3. I decide to switch from the default OSAF calendaring parcel, called "osafcal", to a new shareware calendaring parcel with more features called "sharecal". When I do this, "sharecal" knows how to interpret the original calendar data and takes over control. However my URL to the calendar remains "http://lisamachine.example.com/Chandler/Lisa/Calendars/Personal". This is an important use case because it shows that the exportable path can't simply name the parcel in order to know what to use to access the data. (Possibly "osafcal" registered for control of the "Calendars" hierarchy originally, but then "sharecal" replaced that registration with its own.)

Major options

There are at least two major options for how to layer exportable addresses.

• The option Morgen envisioned is that exportable addresses would only be used when a reference to an item had to be sent outside the system (to another machine, or to a non-Chandler app). This is certainly possible. Parcels could do the translation from exportable addresses to internal (repository) addresses or GUIDs.
• The more invasive option (given the current status) is that exportable addresses would be used everywhere above the repository -- only the repository would use its arbitrary storage paths or UIDs. Here's how that would work, using the example of a new mail.
  • A new mail arrives, downloaded by the "osafmail" parcel. This parcel needs to pick a default exportable address for the new item when it submits it to the repository for storage. The parcel has registered for the path /Lisa/Mail as its location to store mail. It's arriving in the Inbox of the ISP account so it decides to create it in /Lisa/Mail/myisp.account/Inbox/. Finally it just needs to pick a unique name within Inbox, and it chooses "/Lisa/Mail/myisp.account/Inbox/Msg336". (Under the covers, the repository puts it somewhere arbitrary under UserData^?)
  • Thereafter, when the "osafmail" parcel needs to list what's in the Inbox of the ISP account, it can ask the repository what's in "/Lisa/Mail/myisp.account/Inbox/" and the new mail will be returned. (Under the covers, the repository can map Inbox to one collection, or part of one collection, or several collections -- but at least initially, the easiest thing to do would simply be to map to an internal collection)
  • If the user decides to keep a link to the mail in their "knitting-group" folder, rather than have it continue to appear in the inbox, the user would drag it. The most obvious way for the parcel to keep track of that change is to ask the repository to "rename" (really, to rebind) the item.
  • When a request comes in from the outside for this kind of item, the "osafmail" parcel is called up because it's registered as the default handler for URLs beginning in "/Lisa/Mail". The request from the outside uses the same path that the parcel uses to refer to the item so pulling it up from the repository is easy for the parcel.

I'm not clear which of these options is better, today. I'm aware of a couple advantages of the latter, partly because I'm familiar with it.

• It would mean that the repository has more power to make arbitrary internal naming decisions and to change those from release to release. The only thing the repository has to preserve is the exportable address.
• Parcels don't have to parse incoming "exportable" addresses --there can be one address resolver for the entire HTTP listener. Once the HTTP listener strips off the beginning template stuff the rest is automatically in the form used by all parcels.

One of the main open questions for where the exportable addressing should be layered is what layer the repository sharing will work at. Mike and Andi seem to be working under the assumption that two synchronized repositories (or in the sharing use case too) will use the identical UID (and path?) to store and refer to a synchronized resource. I'm not sure that's a good idea, particularly if the two repositories are at different versions. If the two repositories have the same content for /Lisa/Mail/myisp.account/Inbox/Msg336, it shouldn't matter if the two repositories have the same UID or internal storage path, and that could be a good thing -- doing more to keep the two repositories at an arm's distance, independent of each others versions/quirks. If the item that "/Lisa/Mail/myisp.account/Inbox/Msg336" refers to is changed, that's fine -- that's a content update and the remote repository downloads the new content.

-- LisaDusseault - 26 Mar 2004