[Dev] collections and notifications meetup

[Ted Leung]

On Feb 8, 2006, at 10:12 PM, Katie Capps Parlante wrote:

> Several folks have expressed interest in getting people together to  
> talk about collections and notifications, and what we should do in  
> 0.7.
>
> Here's a short list of problems as I understand them:
>
> - The detail view displays the collections that an item appears in  
> -- this needs to be supported efficiently.

Yes, this is a problem.  We originally thought that using monitors  
was going to work for this, but they don't handle all the cases.

>
> - Item Notifications: we agreed to do this at the end of 0.6. (Bug  
> 4592) In 0.7 we'll have automatic syncing for sharing, thus more  
> going on in background threats, thus more need for notifications to  
> the detail view on a per item basis.
>
> - Performance issues. As Andi, John and others were chasing down  
> slow use cases in 0.6, they ran into some thorny issues that we  
> ended up punting.

Do we have bug numbers for these issues?   Or mailing list  
discussions?  I can no longer remember the precise details for this,  
so this is only stirring vague thoughts for me.

>
> - Getting the layering correct. We've described this as "moving  
> collections below the line". We need to: (a) make sure we have a  
> clean reasonable API for collections as used by the higher level  
> layers (b) move application specific details like color out of the  
> generic notion of a collection (c) move collections to the right  
> layer of the architecture -- if collections are as generic as items  
> they belong in a lower layer. We need to do something similar for  
> notifications.

There has been a lot of "seepage" in both directions.   There are a  
bunch of attributes on AbstractCollection which don't belong there,  
and I think that InclusionExclusionCollection and  
IndexedSelectionCollection probably should live "above the line".     
At the same time, there is a bunch lower level repository stuff,  
indexing API in particular which as leaked into application code.

It would be very helpful to have more information about how the  
sidebar actually uses collections - which collection classes are  
being used by the sidebar, what kinds of indexes, and so forth.

>
> Any others to add to the list?

It might help to review the requirements section of the Item  
Collection spec for 0.6 <http://svn.osafoundation.org/docs/trunk/docs/ 
specs/rel0_6/ItemCollection-0.6.html>  The details of the  
implementation are much different from what we ended up with but the  
requirements section is in good shape.  I am in the middle of  
updating that spec, but I will probably not be done in time for  
Monday's meeting

The other thing that I would point out is that the existing  
implementation of notification can only be generously described as a  
hack.   It tries to cobble together the necessary information from  
several sources, the repository's set notifications, the repository  
change history, and some auxiliary data structures in order to  
produce the correct stream of notifications.   It seems to me that  
logical result of moving collections "below the line" would be to  
also modify the implementation of notification and/or the  
implementation of the repository to achieve the semantics that we are  
looking for at the application level.

Ted