Welcome back Alec!
On Jun 23, 2005, at 10:46 AM, Alec Flett wrote:
Hey Ted -
I'm catching up on things and I finally got a chance to read over
this, I definitely have a few questions/issues - hopefully stuff
that just needs to be clarified in the spec but I think there are
things that are not completely flushed out to the application
level. I think one simple issue with the whole spec is that it
assumes some deep background knowledge or implies an obvious
implementation but it isn't always obvious to the reader :)
Part of the problem is that we don't yet have a technical portion of
the sidebar spec, which would tie some of these areas together.
Mine/Not Mine: what is this? r8 doesn't really explain it - Are you
just saying you can flag an Item Collection with arbitrary
attributes and Mine/Not Mine is an example? What would be the
specific application use of "Mine"/"Not Mine" in the context of
chandler? Is this distinguishing Sidebar collections from internal
collections?
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>
You don't flag an Item Collection, you flag attributes and a rule on
the item collection causes those items to be included in the item
collection. It doesn't have anything to do with Sidebar collections
versus internal collections
you start talking about the pros and cons of Extents without really
explaining what they are? I'm sure you and Andi have your heads
wrapped around them, but fill me in :)
An extent is a set that represents all the items of a particular
kind. Think of it as the result of a kind query or a 'for i in //
<KindName> while True" query in the existing system. The issue is
that the existing query system does most queries against
(conceptually) the set of all items of a kind. Now we need an
explicit way to do that. I think that we have a solution for this,
and when the prototype settles down (in a few days I hope) I'll rev
the spec to include the details
The stuff regarding the detail view seems like its beyond the scope
of ItemCollections and I'm guessing its there due to the 0.5
notification system. I have a new idea on that though, that I'll
offer in another e-mail to you and Andi.
Yes, the stuff for the detail view is related to notification.
I'm concerned that the "filtering" system is not really flushed
out. I understand the application level use of filtering from a
user's perspective, but I don't understand how it really gets
reflected at the ItemCollection level. There are no good use cases
in the spec for how it would actually be used in conjunction with
the app bar. I mean:
When an ItemCollection is "filtered" what does that mean for the
collection? How does an app developer know when to "filter" a
collection, and what is the result of the filter? Is a new
"dependent" collection created (as we do in 0.5) or is the existing
collection changed in some way? When the app "turns off" a filter,
do dependent collections go away? if not, are they updated
automatically?
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.
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.
What are the implications for sharing, etc. i.e. if I'm sharing a
filtered collection, am I sharing a dependent collection, or am I
sharing a subset of an existing collection?
As far as you are concerned you only ever deal with a set/list of
items. The sharing code does not know about rules or compositions
(unions, intersections, etc) of sets, or whether sets are implemented
as dependent or not.. You are just sharing the items.
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. When you do this, it will
appear to be part of the contents of the item collection because we
take the items that match the rule, union them with the items in
exclusions, and then remove any items in exclusions.
When an application creates a new event but is dealing with a
filtered collection, can it be added to the filtered collection, or
should it be added to some parent collection? (similar to the
previous question)
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.
You need to know if you are going to add to inclusions or exclusions
because there you are overriding the rules.
John and I have discussed, for months now, the idea of associating
some metadata with an ItemCollection - I don't see that addressed
here, though John and I have some ideas. An example of this would
be, if a collection is displayed with a particular color in the
calendar, where do we store that color? Its calendar-specific
information, but it should be associated with an ItemCollection, so
that the calendar code doesn't have to do housekeeping to make sure
that the metainformation gets cleaned up when an ItemCollection
goes away. And again, what are the implications for sharing? Should
this metadata be shared or not, and is there a way to indicate that?
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.
Ted
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
