Yesterday there was some discussion on #chandler about different methods for accessing "well known" items; example items include: the Contact item that represents "Me", the "current/default" IMAPAccount item, and the outermost CPIA Block item. Before we try to propose a new method, or standardize on an existing one, I thought I should recap what's currently in place.
Currently we have four different mechanisms for finding these:
1) using a repository path (such as '//userdata/me' ),
2) using what I call a "CurrentPointer" item, and
3) CPIA's findBlockByName method (which I believe maps names to UUIDs in a dict)
4) The ParcelManager's lookup( ) method
1) We currently only use parent/child paths for schema lookup and debugging. 2) 3) hmm 4) 5) find by UUID 6) find by ref collection-based path (implemented about a year ago but not in use anywhere as far as I can tell) The proposal for ref collection-based paths I wrote last May is attached. Simply: these paths use aliases into ref collections instead of item names into a child collection. This allows for having multiple paths to the same item since an item can be referenced in multiple ref collections and can have different aliases in each and hence doesn't suffer from the same limitations as parent/child-based paths, items get the gift of ubiquity :)
Having this conversation again is very welcome. I've been working on importing items from one view into another and the issue of matching items across views or across repositories came up again. It seems that ref collection-based paths are a useful level of abstraction to match different items that can 'mean' the same. For example: my 'all' collection is matched with yours in the context of my importing an item from your 'all' collection into mine.
Andi..
Proposal for ref collection-based paths ---------------------------------------
1. Current item locators
Natively, the repository supports two ways of finding any item, by
Universally Unique IDentifier (UUID) and by Path. The UUID works as a
unique and constant persistent pointer to an item that is valid for the
life of the item while the Path to an item is a sequence of intrisically
named items acting as containers describing the item's current location
in the repository. Paths can be expressed relative to any items or can be
rooted with the repository.
There can be only one UUID leading to a given item and there can only be
one absolute canonical path leading to a given item. Because of this
unicity constraint, attaching domain specific meaning to the canonical
location of an item is bound to result in clashes since an item can serve
more than one domain specific - semantic - purpose.
The following is a proposal to implement an additional mechanism for
locating items that is semantically rich and not constrained in the same
ways.
2. Definitions
a. Bi-directional references
A bi-directional reference between two items is defined by two
attributes - the endpoints of the reference - each containing a
pointer to the item being referenced.
For example:
Let 'A' and 'B' be two items and 'p' and 'q' be two attributes
defined on 'A' and 'B' respectively. If 'q' is defined to be the
'otherName' of 'p', and 'p' is defined to be the 'otherName' of 'q',
the act of storing a reference to 'B' in 'p' automatically causes a
reference to 'A' to be stored in 'q', namely:
A.p = B causes B.q = A
and
A.p.q == A
B.q.p == B
b. Ref collections
A ref collection on an item is defined as an endpoint attribute on
this item with a multi-valued cardinality. The cardinality of each
endpoint is defined independently of each other. For example, the
above 'p' attribute could be of 'list' cardinality while the
corresponding 'q' attribute is of 'single' cardinality.
For example:
A.p.add(B) causes B.q = A
and
A.p.get(B).q == A
B.q.p.get(B) == B
A ref collection is implemented as an ordered set of item references
keyed on the UUIDs of the items being referenced. An item can only be
referenced once in a given ref collection. The above get(B) operation
is actually defined as get(B's UUID).
c. Ref aliases
When stored in a ref collection, the reference to an item can be
assigned a name - a ref alias - by which it can also be looked up in
the ref collection. For example:
A.p.add(B, 'b') causes B.q = A
and
A.p.get('b').q == A
B.q.p.get('b') == B
3. Ref collection-based path spaces
A ref collection-based path space is defined by a well-known root and a
directed pair - up, down - of endpoint attributes.
For example:
Let 'R' be a root and 'p' and 'q' be two endpoint attributes having
each other as 'otherName'. Let also 'q' be of 'list' cardinality and
be the ref collection used in the down direction of the path. The
cardinality of the 'p' attribute, the up direction of the path is
irrelevant in this example, it could be 'single' or 'list'.
Dereferencing the path /a/b/c/d in this space is equivalent to the
following operation:
R.q.get('a').q.get('b').q.get('c').q.get('d')
4. Properties of ref collection-based paths
There can be a reference to a given item in any number of ref
collections. Each of these references can be assigned its own name, a ref
alias, independently of each other.
Therefore, while each path leads to a different item reference, these
item reference may yield the same item and:
(a) in a given ref collection-based path space, there can be any number of
ref collection-based paths leading to a given item.
Since each ref collection-based path space is defined a by a well-known
root and a pair of endpoints attributes defined in the data model's schema:
(b) a given item may be referenced by a ref collection-based path in a
given space if and only if it is of a kind declaring the attribute
for the up direction of the directed endpoint pair.
(c) a given item may act as a container in a given space if and only
if it is of a kind declaring the attribute for the down direction
of the directed endpoint pair.
Consequently:
(1) a ref collection-based path space defines a semantic space in
which items can be arranged in a hierarchy.
(2) ref collection-based paths are semantically pure.
5. Implementation details
a. Unicity
(1) A reference to a given item is unique within a given ref collection
(2) An alias to a reference is unique in a given ref collection
While it would be difficult to lift the first constraint, the second
one could be lifted. It is unclear whether this is necessary or
desirable. Having a given ref collection-based path resolve to
several item references instead of one would make exporting such paths
more difficult.
b. Well-known root
It is desirable to define a way to cache the well-known root for a
given ref collection-based path space. Currently, caching the root
item on the attribute schema item for the down direction endpoint is
being considered and reflects the attribute-centric approach used to
define such path spaces.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
