We met to go over this email this morning. Below are some notes in-
line...
On Feb 6, 2008, at 9:53 AM, Mimi Yin wrote:
Stuff that showcases sharing:
+ Rolling account history - who's doing what in which collections,
when with clickable links to individual items and collections
+ List of Hub contacts + pictures
Jeffrey clarified that what we really want is a way to see who's
sharing a collection with you.
+ Poke a subscriber - some way to 'notify' another subscriber about
a particular item / collection
II. LIST OF QUESTIONS RE: WHAT SERVER/WEB APP SUPPORT TODAY
1. What are the biggest data integrity issues? When will people see
inconsistent data between desktop / web app / web widgets? I don't
think we need 100% data integrity across all Chandler access
points, but depending on what web widgets we build, the design will
require different degrees of data integrity.
More specifically, can we maintain consistency wrt the following
Chandler behaviors?
+ When shared items pop to NOW because they were newly created or
edited by a subscriber
+ Auto-triaging to NOW based on event date and alarm date?
+ Manual override of triage status
+ Byline
+ Read/Unread status
Less important behaviors to 'get right' across Chandler access points
+ What appears in Who / Date columns
+ Knowledge about items living in multiple collections
+ Triage Status ordering?
I know there are also issues wrt recurrence and time zones, but I
don't understand them well enough to formulate specific questions.
But again, I'm most interested in preserving data integrity across
access points.
Some Rules of Thumb to follow:
1. We should think of our starting point as EIM. Whatever is stored
in EIM, the server can serve up to any web widgets we build.
2. Expensive items: Anything where you care about per user
attributes. This includes things like 'Read/Unread' status and
sharing filters (what attributes are shared/not-shared with others).
* We can probably still provide functionality around tell people
'what's new' in their collections even without read/unread status by
asking users to define a timeframe: Show me everything that's changed
in the last hour OR by automatically showing users everything that's
changed since the last time they logged in. The latter approach might
be problematic if Desktop users are subscribed anonymously via
tickets to certain collections. We would want to be able to figure
out the last time the Desktop synced with the server with a Hub
account and assume that that's the same time they synced all their
subscriptions as well.
* We will probably still want to add things to EIM. Need to get
further along in design to figure out what it is we need to add.
* I realized after the meeting that sharing filters: what attributes
get shared/not shared from the desktop, fall under the category of
expensive per-user attributes we're unlikely to support anytime soon.
Does that mean that in order for your web widget to know about alarms
you've set on an item, you need to share alarms with everyone else as
well?
To partially address this problem, we could differentiate between
custom-date alarms (shared) and alarms dependent on event-times (not-
shared). It means that if you're using your web widget, you won't
receive alarms you set on events like alert me 15 minutes before the
meeting (unless you're okay with sharing that with everyone else as
well.)
I think this, like 'items in multiple collections below' is something
we can live with in the short-term, but want to address in the long-
term.
2. Can we link to individual items? Do we need to be able to do
that to do the detail view widgets? What if you want to share
individual detail views? Is that different from accessing a detail
view you created or subscribed to in a shared collection?
+ Yes the server can generate read-write and read-only tickets
+ We can also create a link to a particular item, within an account
+ We just need UI to display a single item. So a single-detail view
widget that you can share with others using tickets is not an
unreasonable feature to add to our queue.
3. What happens if we sync ALL Desktop collections to the Hub? How
will the OOTB (Dashboard, In, Out, Trash) collections interact with
the OOTB HUb collection? Will the server /web app/web widgets
understand about how adding items to 'MINE' collections
automatically adds the same item to the OOTB collections? What
about deleting items and putting them in the Trash collection?
Need to come back to this on Monday.
4. How hard is it to get the 'behavior model' right for sharing
read-only and read-write items and collections? From the cosmo
channel conversation we had today, it seems like it'd be a lot of
work. http://chandlerproject.org/script/getIrcTranscript.cgi?
channel=cosmo&date=20080205&startTime=1411
The 3 design requirements I was finally able to articulate were:
+ Allow for individual items to have different permissions than the
collections they belong in
+ Understand when read-write access overrides read-only access and
vice versa on individual items
- If you create an item, you always have read-write access, even if
you receive it read-only later on
- If you receive an item read-write and read-only, you have read-
write access
- If you receive an item read-only and add it to a read-write
collection, you do *not* gain read-write access
+ Silo items that are published to server without explicit read-
write or read-only access as copies stored in a separate collection
+ Perhaps in the short-term, we can rely on desktop users to
reconcile edits to items in multiple collections
+ However in the long-term, we will need a more sophisticated
solution to our security issues that allows the server to understand
about items in multiple collections.
Randy to come up with a proposal for how we deal with this issue.
III. HOW DOES THE CURRENT WEB UI FIT INTO OUR NEW ECOSYSTEM?
What do we do with current web UI?
+ Keep it around for existing users
+ Do we stop directing new users to the current web UI? (i.e.
Remove the Log in link from the account confirmation page?)
+ Do we port the current codebase to Dojo 1.0?
+ Do we continue to maintain it? (i.e. The task stamp on the
Desktop is now going to be a star stamp. Do we update the web app
to reflect that change?)
+ At what point do we offer up a an alternative web widget UI and/
or a gallery of web widgets when users log in instead of the
current web app?
Another way I've been thinking about the web strategy is: What
needs to be consistent with what?
+ Web widgets + Desktop?
+ Web widgets + Web App?
+ Web App + Desktop?
+ Server and all of the above?
Pick this up on Monday.
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
