Re: [Dev] Item Collection Spec 0.2

[Alec Flett]

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