[Dev] New iterItems() convenience API

[John Anderson]

Although I think queries are very important, I think andi's ref 
collections (and soon sets) can better address many of the problems 
you'd typically use a more traditional query for. They can make it 
really easy to "hook up" new parcel pieces to existing pieces of 
chandler, something that's awkward or slow to do with queries. There are 
relatively efficient, scale well, can persist result sets, keep track of 
ordered lists and provide notifications about changes to the UI. It's 
important to understand all the tools at our disposal and use the right 
tool for the task, rather than depending upon on a single tool, e.g. a 
traditional query.

John

Phillip J. Eby wrote:

> 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
>