As of July 2002, renaming a page will break links to that page in other wiki-style pages. This represents a significant (and annoying) difference from Swiki. The solution space is complicated by two things:
- Synchronous interaction support. Unlike Swiki, we cannot rely on being able to process every edit as a transaction.
- Security. Also unlike swiki, the user who initiates a name change may not have permission to change links on other pages.
The bridge EmbeddedObjectDescriptor includes a notion of an immutable unique ID for each object. This was originally concieved of as part of a solution to the general problem of preserving referential integrity when objects are renamed or shuffled within a given container. This is used successfully on most (hopefully all?) objects that support structured selection of objects within the same EmbeddedObjectSet (directory). For example, objects that are embedded on a whiteboard are identified by UID. The early transactional text editor object also used these, but the scheme used for encoding the UIDs within the text data would not work with the synchonous editor.
As new object types have appeared, the problems with embedded object names, and more generally object paths, have multiplied. Whiteboards, maps, templates, WebSites (directories), and others can include paths to objects. While problematic, unique ids (or CORK ObjectIDs) are not sufficient as substitutes for paths for a number of reasons:
- Readability. To ensure uniqueness, ids must be machine-generated and opaque.
- URL generation. While technically possible to contruct a URL for viewing a specific object based on object id, a URL based on object path is more presentable.
- Security support. CORK
Permissions objects are fundamentally associated with replicated objects and have no direct knowledge of paths, but permission semantics are closely tied to paths, e.g., the default permission setting for new objects is "same as container".
- Synchronous awareness support.
ObjectSessionData and related classed use path information to track which users are accessing which objects. (See Synchronous awareness support)
Possible solutions include:
- Have a server-side entity that listens for name changes and bulk-processes all pages in the site.
- Running this on the server (potentially) eliminates security issues
- but this approach has considerably scalability implications, not just because of the number of objects, but also because of the number of types of objects which support linking or embedding
- Augment the underlying data object (e.g., SynchronousTextData) with a table of names-to-uids for all named links that were known to be valid at some point. Broken links (detected either when rendering a web page or doing syntax highlighting in the live editor) could be checked against this table, and the document updated as needed.
- Flexible, since roughly the same mechanism works on either client or server
- Mitigates security concerns, since links can be fixed "on the fly" for users who have read-only access to the data
- but requires changes to Externalizable classes, which may break existing serialized versions
- but would need to be generalizable to other kinds of objects that support linking/embedding
- Provide better support for manually fixing broken links. This could include popup menus available on individual links as well as tools for bulk-replacing links. A bulk-replacing mechanism would be generally useful for other tasks.
- but would not address web-editing. However, given that it is not currently possible to rename things from the web interface, this may not be as much of a problem.
- Introduce an object that tracks links within a site. Such an object could provide navigable visualizations of the site structure, as well as maintain (source object uid, dest object uid, dest object name in source object) triples for automated updating.
- Eliminates need to change storage for sync doc-related classes (thereby avoiding likely problems with
Externalizable).
- but may become large
- but would have to be accessed for every page operation
- but may present security problems
- but the visualization could also be derived from the parts of the site accessible to a given user using the data from solution (2)
- Introduce a relational structure that maps cannonical names (paths) to CORK
ObjectIDs.
- would provide a definitive way of finding a usable path for an object, assuming we have the object id
- as a side-effect, would simplify garbage collection tasks
- but would require storing object ids in SyncTextDocuments, as possibly other places where we are not currently storing them. This is potentially a problem for web-editable objects since object state must generally be "flattened" to accomodate the limitations of web forms.
- but would introduce a dependency on a relational database, making system setup and maintenance somewhat more complex.
- Introduce additional meta-data support in CORK that would allow connonical paths (and other information) to be associated with replicated objects.
- would eliminate the need for using a relational database for ObjectID->path mapping
- should be faster than a database lookup
- but the implications of having metadata attached to objects and to object locations (e.g., EmbeddedObjectDescriptors) needs to be considered.
Notes:
- Version chains (linked lists of old object versions) will need to be considered in any of these approaches. Should the paths associated with old versions be updated when an object path changes, or should they reflect the path at the time that the version was created?
- Maintaining old paths would provide additional history information, showing the name and location of the object over time.
|