Notes

Notes from bkirsch code review

Code review items to add to a master list somwhere

• justification for preferring import mypackage.mymodule as mymodule to from mypackage import mymodule (from copies names but doesn't link/alias them - see Learning Python p. 286-287)
• use super(Class, self).method rather than Class.method for invoking super
• the Python flag for debug mode is __debug__
• use logging
• use epydoc

General items

• move twisted specific functionality out of parcels.osaf.framework.twisted.RepositoryViewBase and make this class fully abstract (this class should probably move to the repository, and hopefully eliminated or substantially reduced by Glyph magic in Twisted). Then create a twisted specific subclass to use for Email
• the Pin API was used inappropriately -- Pinning was never followed by Unpinning, validating concerns that pinning will be error prone for developers
• we may want to do some more work on logging in terms of giving options for what happens to the log, etc.

Item Clouds

Rough (abstract) definitions

• these need to be rationalized vs the current implementation

• a attribute path is a list of attribute names that can be traversed in path from an Item of some Kind (the path root) to an endpoint Item
• a cloud consists of a root Kind and a set of attribute paths.
• a kind may have more than one cloud associated with it? both overlapping somehow, or cloud endpoints that are roots of other clouds
• given an item of the root Kind (root item), the set of items that is reachable from the root item is the set of items in the cloud. There is a comparable notion at the Kind level, which is the set of Kinds in the cloud
• a cloud may have one or more policies associated with it

Thoughts from yesterday's IRC regarding item clouds

• BrianK brought up the case of a mail message, cloud1 which contain a MIME part where the MIME part itself is a message cloud2. The question is whether a clould can be a "part" of another cloud, and what does this mean.
• This immediately led to a discussion of clouds being non-overlapping. I think that we are going to discover the enforcing the non-overlapping nature of clouds is going to be very expensive. The only way that I can think of to do this is to take each Kind and compare each cloud with every other cloud in the system. For small numbers of clouds this might be feasible. In order to make cloud comparison tractable, we will probably need to store the attribute paths that make up a cloud in some canonical form so that comparisons can be fast. The data model is going to add support for adding/deleting kinds to a base kind. When this happens, items will gain/lose attributes, which will cause their membership in a cloud to change. As long as actual cloud definitions cannot change at runtime, then we only have to do the non-overlapping test when a new kind with clouds is added to the system.

-- TedLeung - 01 Jul 2004