Attending: KatieCappsParlante, BrianDouglasSkinner, AndiVajda, TedLeung, JohnAnderson, MitchKapor, MimiYin, LisaDusseault, ScottRosenberg (observing)

Next Actions

• Design team owns the requirements, design team to put together requirements. See http://wiki.osafoundation.org/twiki/bin/view/Jungle/DesignRequirmentsNamesAndAddresses
• Lisa owns pulling together the next iteration of the addressing proposal, sans design issues

Design Requirements (from the column on the whiteboard)

• User facing addresses for
  • Item clouds
  • Collections
  • Views
• Supports navigation, sharing in Chandler
• Multiple addresses per item are needed (how?)
• read it, copy it, click on it
• change? can the user change these? when?
• canonical organization?
• permalink

• names
  • uniqueness of names issue (names don't need to be unique)
  • collections and views need to have user selectable names
    • should be able to include spaces and any character or glyph
    • restricting the slash might be ok
  • ideally, an address should include the user-facing name
  • a "path segment" is derivable from a name

• what are "bread crumbs"?

Notes

• John talked about "locations" in CPIA
  • the app keeps track of a tree of nodes
  • each node is a view (ItemCollection)
  • the tree of locations is like a file system
  • the tree of locations is used by the navigation system (url bar, forward/back buttons, sidebar)
  • the repository viewer walks the repository path (separate hierarchy)

• Lisa talked about ExportableAddressesJun2004

• Questions from Brian's notes:
  • One or many addresses to each thing?
  • Should addresses be invariant?
  • Should addresses change when users move or rename things?

• Design requirements from Mitch (a longer list above)
  • Q: What are the things in the user's mental model?
    • A: Items (Item Clouds), Collections, Views
  • Individual users manipulate items, collections and views
  • Views appear in the sidebar
  • Users drag these things around
  • Items, Collections and Views can all be shared
  • We want the address scheme to be usable by non-chandler clients
  • The proposal needs to address the issue of having "permalinks" (a la MovableType)

• Mimi: the path to an item, or breadcrumb train, can be different from the address of an item
• Mimi: instead of thinking about the address as the location, or path you took to get somewhere, perhaps use attributes of the item to determine its address. Think of items as being in a web, not as being in a deeply hierarchical directory structure.
  • follow up idea, using uuids unburdens you from thinking about location as the address (or name, or identity) of something
• Andi: sharing a location is different from sharing an item (subtly different concepts). If you share a location, there is a level of indirection, the item at that location can change.
• Is the address space a hierarchy? Is it the repository path? There is probably some delimited path
• An address space needs to enable traversal, in particular for non chandler clients
• It can be useful to have a fixed or unique way to find something
• Sometimes a user wants to share a collection, not the individual items in a collection. If an item moves out of the collection, it is no longer shared.

-- KatieCappsParlante - 12 Apr 2004

---

See also

Warning: Can't find topic Trash.PagesAboutAddressing