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 :)
- 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?
- 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 :)
- 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.
- 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?
- 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?
- 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?
- 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)
- 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?
I think that's it for now....
Alec
Ted Leung wrote:
I've committed a new revision of the Item Collection spec
<http:// viewcvs.o11n.org/docs/trunk/docs/specs/rel0_6/
ItemCollection-0.6.html>. This version incorporates all the
feedback that I've received so far.
The section on notification has gotten more detail, and there's a new
section with some sample code. That section presents
several alternative designs for the APIs.
As always, I'd be grateful for your feedback.
Ted
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
