Hey, Philippe
Sneaky of you to ask me a question right at the very, very end
there :). A couple of answers/comments inline below.
--Grant
On 7 Mar, 2007, at 15:14, Philippe Bossut wrote:
...
First, I'd like to clarify that the text here above doesn't refer
so much to what goes into the byline than to what must be saved
into the item's lastModifiedBy attribute. It's clear for instance
that, if you sync the Office Calendar and select an item (say an
event) created by Helen the Hub on Monday, you are expecting the
byline to say "Created by Helen on 03/05/07". The problem with the
byline as implemented right now in the trunk (a placeholder for the
real thing for sure) is that because the lastModifiedBy attribute
is always set to None, all item say "Created by me on
<displayDate>", even when, clearly, I've nothing to do with their
creation.
So the byline text should be something like:
<edit type> <lastModifiedBy> on <displayDate>
To clarify this clarification, in Chandler the attribute you're
calling "displayDate" is actually "lastModified". (The "displayDate"
attribute is a column in the Dashboard).
- <edit type> must be chosen as appropriate within the following
list: Created by, Send as, Sent by, Edited by, Updated by
Yes, and the "Send as" and "Edited by" cases can have a drop-down
control, but the others are just static text controls.
- if <lastModifiedby> is None, then the "by/as <lastModifiedBy>"
section is not displayed (that's the change suggested by Bryan IIUC).
- displayDate being always present, I don't think there's a case
where we don't display the date... or is there?
I think there will always be a date to display (though it's not
technically displayDate, as above). We do have to fall back to
createdOn (instead of lastModified) in some cases.
...
Issues:
- For an item I (local user) edit, it appears that the transition
from "Edited by" to "Updated by" happens after the next sync
(manual or background). Is that correct?
Well, it's what I intended :). From the sending client's point of
view, we have to package up the item into an email and hand the email
off to your SMTP server. We only really know the item has been sent
when the server accepts it(*). So, the "sent" state (or possibly
"error" state) only happens well after the item has been emailified.
It's certainly possible to try to get tricky, and pre-mark the item
as sent and attempt to restore its old state on failure, but for the
moment I think it's better to keep things simple.
On the other hand, the recipient of an email item knows that it has
indeed been sent (or updated), so perhaps in this case the proper way
to share this state correctly (have recipients update the
lastModifiedBy/lastModified/lastModification).
- For an item which is both shared and emailed, I suppose the
emailness overwrite the shareness and then the byline should say
"Send as <lastModifiedby>" rather than "Edited by <lastModifiedby>"
when editing. What if the item is synced but not sent? I still
think it should say "Send as" and not switch to "Updated by" (i.e.
emailness always win). Is that ok?
Actually, the stamping spec currently has this the other way around.
- Ideally, Chandler should have a notion of "edit session" and be
able to share that state so that a shared item could be seen as
"Edited by". I'm not sure we can get to that for Preview, can we?
There's some domain model change here (if we need to share that
state) so I'm expecting Grant to pipe in
I'm not sure if we're meaning the same thing by "edit session", as I
don't see what they have to do with sharing. As they've been proposed
so far, an edit session encompasses the time you're viewing a
particular item in the detail view. The proposed usages are:
1) If you create a new item, its byline says "Created ..." until you
finish the edit session -- i.e. select another item/quit the app.
2) It has been proposed in Bug 8242 that your first answer to a
recurrence dialog question (all/all future/this) "sticks" for that
session, to avoid having repeated appearances of the dialog.
--Grant
(*) Actually, even this isn't really true, but now isn't a good time
into discussing SMTP server implementations.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
