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.
Ultimately though, the hope is that there is going to be a lot less use of
KindQuery once the new ItemCollection/Query/AbstractSet stuff becomes
mainstream.
Basically, a KindQuery should be a query of last resort. Using sets, which
ultimately wrap one or more ref collections is a lot more efficient.
I'm not sure I follow you here; there will still be situations where the
desired behavior is to obtain all items of a particular kind, and the ideal
API is simply to ask a class to iterate its items. For example, all items of
the Web.Server kind need to be found in order to set up listening ports.
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.
The issue of looking up that item is part of the larger 'Addressing' issue
that Katie has on her plate at the moment.
Iterating over a ref collection is more efficient than running a Kind query,
which itself isn't that bad, it's just a big hammer and usually the wrong tool
for the task.
Of course, if efficiency requires a different implementation for iterItems()
then that is easily achieved since there is now only one place needed to
change it. (Not entirely true, actually, as there are still KindQuery uses
floating around that I haven't converted yet for one reason and another.)
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. 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.
A KindQuery should be used when there is no such root or well known entry
point that is easily navigatable to finding the items of interest.
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.
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
