At 08:55 AM 6/25/2005 -0700, Andi Vajda wrote:
So, the Kind method would only be useful in situations when you already
have a kind object -- and I'll be trying to eliminate those situations as
much as possible. :)
Anytime you have an Item object, you have its Kind object, so I'm a little
confused by what you're saying here.
In the Chandler code base, kind queries were being used where there was
*no* item or kind available, only a view. So code was doing either
SomeClass.getKind(view) and kind-querying that, or else doing
view.findPath() to look up the kind.
Instead of looking for all items of Kind Web.Server, you could have all
such items sit in a 'servers' attribute (a ref collection) of another item
such as a Web.Servers item which is responsible for starting or managing
all such
servers. That Web.Servers item would itself be looked up via a well known
path - not a parent/child path but a ref collection based path for example.
That adds complexity to the API exposed to parcel developers; currently a
developer can simply create the item, without needing to link it to some
other object. It also means the OSAF developer creating an extension point
needs to set up and document these "well known" paths.
More than an efficiency issue, there also is a paradigm issue here. The
Chandler repository is not like a relational database where you use some
fancy query to find exactly what you want.
Key phrase: "exactly what you want". :) As far as I can tell, a kind
query is indeed exactly what the developers who used them wanted, at
virtually all of the places I found them.
In Chandler's case, the repository is being used as a single-user database
for a single application; this means that for many object types, the
natural working set is the entire class extent. For example, one does not
need to have POPAccount instances that are *not* used by the Accounts
dialog. In fact, it would be a bug to have such a thing.
It is more like an object database, that is, a persistent graph of objects
which the application navigates. That graph has well known entry points:
roots or well known paths remaining to be spec'ed when solving the
'Addressing' issue.
You're describing a hierarchical or network database, or a simple object
store; object *databases* generally support intensional sets and querying
against class extents without any requirement to reify queries as
navigation. Indeed, relational databases mostly replaced hierarchical and
network databases because they don't require programmers to design and
manage their own navigation structures.
Defining these well known entry points means to:
- define an addressing scheme (ref collection based paths is my proposal)
- define a schema that contains all these commonly used collections (all
web servers as per your example above)
Currently, the Chandler application schema is in flux, the
ItemCollection/Query stuff is being redone and the 'addressing' issue is
not settled. Once it is, we can define well known addresses to repository
entry points containing collections of items of interest.
Until then, using KindQuery is the usual starting point but I do hope that
once these issues are fixed, we use it only as last resort.
I don't see any actual conflict here; what stops you from simply
maintaining kind-extent sets internally as part of this new addressing
paradigm? Do you intend not to support intentional sets at all, only
extensional ones? Because if so, I think that's going in a bad direction
for developer comprehension and usability. This is one of ZODB's bigger
flaws: it has no inherent mechanism for efficient queries, but you instead
have to reify sets as navigation extents, such as via ZCatalog.
Currently, parcel definition is quite simple because for many kinds of
things, you can simply toss an item in the bucket and have it work, without
needing to know about anything else. It's sufficient to create a web
server item or wakeup caller item (or RSS feed, or any number of other
things we haven't invented yet), and it "just works". I'd hate to throw
away that feature just so we can make the repository into a less
generally-useful database.
Anyway, all database paradigm discussion aside, my main point is that
iterItems() is an easy and obvious way to provide extension points for the
Chandler platform, that are easy for parcel developers to extend by simply
creating items and having them be automatically discovered. I'd prefer not
to have the feature go away and then be forced to simulate it at the schema
layer, e.g. by creating an 'extent' biref from Kinds to their Items and
making schema.Item.__init__ add all items to the extent. This just seems
like busywork to me, as well as duplicating the half-biref that already
exists from items to their kinds.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
