Notes from some conversations during the week...

addresses and the application

John had a proposal that went something like this:

• Think of the repository items as being divided into three categories:
  • Core data model (Kind, Item, etc.)
  • Items defined by parcels
  • Items created by the user (instances of ContentItems, instances of Views and Blocks, instances of ItemCollections)

• Items created by parcels and items created to bootstrap the repository, lets just use the repository path. Use the repository path in the "address" for these items, perhaps have some prefix to separate out this space. For parcels, continue to let the directory structure mirror the repository path. If this creates some restrictions on the address of these items (only one address for each one), its not so much a problem.

• If an item described by a parcel is to be used as user data, and customized by the user, then think of the version in the parcel as a "template". Copy the item to the user's space when the parcel/extension is initially loaded. Think of the items defined by parcels as read-only.

• User data items can live in some other part of the address space. These items could potentially have multiple addresses. The repository path is thought of as an implementation detail (some path is picked, but the client code is unaware of this path). If the user sees any address space, they will see this address space. Sharing should use this same address space. If the code ever needs to look up an item by a name (vs uuid or reference or query), it will use this address.

• Use Andi's proposal for managing the "address" space for items, essentially storing a "path" of itemRef names that makes up the address. If another implementation makes more sense, that works too. The assumption is that we need some higher level repository structure for user data addresses.

• It would be great to only have one hierarchy to know about. If that's a problem, then at least only have to worry about one hierarchy for each class of items. In parcels, items are associated with python code, which lives in a hierarchy that mirrors the filesystem hierarchy of where the python modules live. It would be best for the programmer if this hierarchy was one and the same. It would be best if the programmer had one place to find things.

Questions/open issues:

• What is the actual address space/hierarchy?
• What role to ItemCollections play in this address space?
• Do we have some immutable address for each item, that has no relationship to the ItemCollections it is in (using UUID, for example)?

notes after the conversation

• Lisa is coming up with a proposal for the address space, which will presumably address the open questions listed above.
• We still have some confusion/overlap between "address", Morgen's proposed registry lookup for services/advertised symbols, and repository itsPath.
• We still have goals of unification: one API, at most one place to put something from the client's perspective.

-- KatieCappsParlante - 17 May 2004