[Dev] Item Collection Spec 0.2

[John Anderson]

Doesn't Andi and Ted's set idea, addresses the notion of most of these 
issues?

Alec Flett wrote:

> One general concern that I'm having is that the ItemCollection spec 
> seems to be very focused on rules and setting attributes on items as a 
> way of including them in collections...  Chandler, as an end user 
> application, deals primarily with ItemCollections of arbitrary items, 
> created by the user, with no particular "rule" binding them together. 
> i.e. a user creates an item, or drags it from one collection to 
> another. There's no "rule" per say on most collections - we need to be 
> thinking more about the use cases of inclusions, not rules.
>
> The only collections focused primarily on rules are "All" and maybe 
> this "Mine/Not-Mine" bit. Yes, you can imagine others, but its not the 
> common case.

>
> Ted Leung wrote:
>
>> Mine/Not Mine is a feature of the sidebar.  See section 5 of 
>> <http://svn.osafoundation.org/docs/trunk/docs/specs/rel0_6/Sidebar-0.6.html>   
>>
>
> (cool, so it might be useful to at least x-reference & link this in 
> the IC spec so readers understand its purpose)
>
>> When you filter, you apply a boolean condition to each element of a  
>> set, " retaining" those items which match the collection.   You  
>> filter a set by creating a filtered set, just like creating a union  
>> or intersection.
>
> except that the filter seems to be applied after the inclusions has 
> been processed, whereas rules seem to be applied before the inclusions 
> are processed. Do I have that right? This has implications, see below..
>
>> That filtered set is then the thing that you interact with.  You  
>> still have access to the set that the filtered set is based on.  The  
>> filtered set is dependent on the original set, and changes to the  
>> original set will cause the contents of the filtered set to update.   
>> If the app wants to turn off the filter, it can go back to  
>> referencing the original set.
>>
> Right, I guess the use case you describe conflicts with how Chandler 
> uses filters today, and I'm not sure which model is the expected one 
> for Chandler going forward. Today, Chandler creates a sort of "child" 
> collection which is a filtered version of an existing collection. You 
> can get to the original collection via the .source attribute on the 
> filtered collection. How should this be implemented going forward?
>
> When you say you're "interacting" with the filtered set, I'm trying to 
> understand the actual implications of each operation (add/remove/etc) 
> when the filter itself is added and removed.
>
> Here's a real world example: if a ItemCollection has a "Task" filter 
> on it, but I call ic.add(event) where event is not a task, what is the 
> result? Does the add() fail, or does the event get added to 
> inclusions, but not actually show up as a member of the collection 
> since its not a task?
>
> Or what if I .remove() an item that's in inclusions, but doesn't match 
> the filter?
>
>
>>
>>> What are the implications when adding new items such as when you  
>>> create a new item and put it in the collection? If it doesn't match  
>>> the filter (i.e. adding a CalendarEvent to an ItemCollection  
>>> filtered on Tasks) does it get added to "inclusions"? does it  
>>> appear to be in the filtered collection or not?
>>
>> If you want to add an item which doesn't match the rule then you 
>> will  need to add it to inclusions explicitly.
>
> do you mean via .add() or via some other mechanism? It sounds like 
> filters trump inclusions, and inclusions trump rules.
>
>> If you have a collection based on a rule/filter then creating items  
>> that match the rule is sufficient to get them into the collection.    
>> Most of the time, you shouldn't need to worry about where to add  
>> stuff, you should let the rules and extents do that work for you. 
>
> This is what I'm talking about : /Most of the time/, the app does care 
> where to add the stuff. /Most of the time/, the user is creating or 
> deleting an event in a specific collection, not writing rules.
>
>> If you want to associate metadata with ItemCollection then we should  
>> have an Item Collection kind where that data can live.   If you add  
>> the metadata as attribute of the ItemCollection kind, then the usual  
>> sharing mechanisms (clouds, etc) apply.   I'd be interested in 
>> seeing  your ideas for how to do this.  I've been focusing mostly on  
>> straightening out the basic semantics, and I haven't gotten any 
>> other  feedback about metadata.
>>
> Its not that I want to associate specific metadata with 
> ItemCollection. Its that we need a generic way to associate ANY meta 
> data with any specific item collection.
>
> More specifically, ItemCollections should not have a "calendarColor" 
> attribute because that's calendar-specific.
>
> Alec
>
>> Ted
>>
>
>------------------------------------------------------------------------
>
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
>Open Source Applications Foundation "Dev" mailing list
>http://lists.osafoundation.org/mailman/listinfo/dev
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/dev/attachments/20050623/8ed43e04/attachment.html