Ticket #303 (closed todo: done)
Interface to Placement index
| Reported by: | ichthyo | Owned by: | ichthyo |
|---|---|---|---|
| Priority: | normal | Milestone: | 0integration |
| Component: | lumieraProc | Keywords: | interfaces design |
| Cc: | Blocked By: | #79, #302, #352, #372, #407 | |
| Blocking: | #115, #304, #440 |
Description (last modified by ichthyo) (diff)
Shape the PlacementIndex interface, decide how to expose it to clients and document it.
Change History
comment:3 Changed 2 years ago by ichthyo
- Status changed from new to accepted
now working on the Placement-Scope topic
comment:6 Changed 2 years ago by ichthyo
- Blocking 115 added
(In #115) there is an interconnection to the query facilities on PlacementIndex: what form of "placement" (language ref, PlacementRef, equivalent Placement instance) is acceptable when invoking query operations?
comment:8 Changed 2 years ago by ichthyo
- Blocked By 340 removed
(In #340) This task has been shifted over from the PlacementIndex to ContentsQuery, while the index is now a rather low-level implementation facility. As far as I can see, the more generic query operations are coded up; but there should be a conclusive list what will be required by the public session API
comment:10 Changed 2 years ago by ichthyo
- Keywords session removed
- Priority changed from grave to normal
- Blocking 79 removed
- Blocked By 79, 440 added
what remains here is mostly checking the sanity of the design done thus far
comment:12 Changed 16 months ago by ichthyo
- Status changed from accepted to closed
- Resolution set to done
- Description modified (diff)
closing that now...
This topic is somewhat strange. PlacementIndex started out as an important API and mutated into a core facility within the session, but almost completely shielded from client code by now. Anyway, the PlacementIndex interface survived some months and implementation of several facilities built on top by now, without significan change, and thus can be considered final.
