yet more on addressing

Ted asked for the different address spaces/uses of addresses: (Lisa has a concrete proposal for exportable addresses at ExportableAddressesJun2004)

• user items: ItemCollections, ContentItems -- includes "ResourceItems" if these differ from content items
  • these are shared and require exportable addresses
• user view/block instances
  • at least a subset of these (views) are shared and require exportable addresses
  • it may prove useful to have a full block/view hierarchy of the application, as a separate "address space" that could be navigated by an application builder
• items as they are defined in parcels, probably in a hierarchy of contained extensions
  • block definitions
  • kinds, attributes in general
  • content model kinds, attributes
  • ootb view instances, block instances
  • task definitions, scheduled task instances
• kinds, attributes
  • base kinds, attributes
  • content item kinds, attributes
  • all kinds, attributes?
• scheduled task, block definitions
  • is it enough to define these in parcels? do we need to find these items using some other address space?
• scheduled task instances
  • these get registered with the task manager, and managed as such afaik. perhaps worth following up w/stuart

IMHO, the extension manager's naming service should complement these hierarchies. The extension manager should create the parcel address space as it loads parcels. A given extension may register itself with the naming service, as a way of registering ootb view instances, scheduled task instances, and other services that the extension might provide. "Registering" is likely a matter of adding an attribute reference to some item, so that the list of task instances/ootb view instances/etc. remains data driven. -- note, I'm perhaps fuzzy on this and need to clarify again w/Morgen

This info needs to make it into my ZeroPointFourExtensibilityProposal, and needs to be consistent w/Morgen's proposal: MorgenSagenSandbox2

-- KatieCappsParlante - 24 May 2004