handling of outgoing items
Mark Hammond
I've a few questions regarding 'sent/outgoing/draft' messages for you
:) I'm hoping we can discuss some of these in our meeting tomorrow, as
the answers here will have significant impact on how we model this
stuff. And speaking of which, it seems possible I might be 10-15
minutes late for the meeting...
The questions:
* General questions about the interaction between local storage and the
API/back-end - the compose mockups save the drafts to local storage - at
what point is it expected these will be handed off to the back-end?
Does the back-end/API need to track these at all, or is it limited to
only the delivery of the message? IOW, does the back-end need the
concept of 'draft', or only of 'sent'? If it does need 'draft', how
does this interact with local storage?
If the backend must track these item, then:
* Do "draft" or "outgoing" items need to be a "real" Message? For
example, will the /message api be expected to deal with draft message
IDs? Will they be returned in /conversation API calls or searches? If
you ask for items "from me", will they appear in the result list?
* Must the type of the message be chosen as the draft is created? IOW,
must the decision about whether a message is an 'email' or a 'tweet' be
made before the draft is first saved, or can this determination be made
later (eg, at 'send' time depending on the selected recipients, etc)?
* Will we require that a single outgoing message could be sent via
multiple protocols? For example, imagine we had facebook integration -
could a single message be marked as both a tweet and a facebook status
update?
* Consider a 'sent' item which is also received by an IMAP server (not
all sent messages will be). Must these 2 versions of the message be the
same message (ie, must they have the same ID, or can they have different
IDs, meaning they might appear in searches etc twice?)
The questions to these answers will impact how we represent
outgoing/sent messages in the data model. In particular, some of the
answers might mean we need to split the 'content identity' table out so
that the 'provider, provider_id' tuple becomes a 1:many relationship -
ie, that a single logical message may have multiple "providers".
Specifically, we might need a new 'provider' of 'outgoing', then when we
receive that same message back via IMAP, we now have an additional
provider of 'email'. For the twitter/facebook example, we might have 1
Message with *3* providers - 'outgoing', 'twitter' and 'facebook'.
Talk to you tomorrow...
Mark
Shane Caraveo
> Hi all,
> I've a few questions regarding 'sent/outgoing/draft' messages for you :)
> I'm hoping we can discuss some of these in our meeting tomorrow, as the
> answers here will have significant impact on how we model this stuff.
> And speaking of which, it seems possible I might be 10-15 minutes late
> for the meeting...
>
> The questions:
>
> * General questions about the interaction between local storage and the
> API/back-end - the compose mockups save the drafts to local storage - at
> what point is it expected these will be handed off to the back-end? Does
> the back-end/API need to track these at all, or is it limited to only
> the delivery of the message? IOW, does the back-end need the concept of
> 'draft', or only of 'sent'? If it does need 'draft', how does this
> interact with local storage?
>
> If the backend must track these item, then:
>
> * Do "draft" or "outgoing" items need to be a "real" Message? For
> example, will the /message api be expected to deal with draft message
> IDs? Will they be returned in /conversation API calls or searches? If
> you ask for items "from me", will they appear in the result list?
I think that would be an ideal way to show drafts
> * Must the type of the message be chosen as the draft is created? IOW,
> must the decision about whether a message is an 'email' or a 'tweet' be
> made before the draft is first saved, or can this determination be made
> later (eg, at 'send' time depending on the selected recipients, etc)?
Preferably the type of the message should wait until it is actually
outgoing. Some hints about the type should be kept, e.g. I am replying
to a tweet from Bryan. But when my message becomes a 4 page rant, it
wont fit into a tweet, fortunately my contact info has Bryan's email
address and the message can still be sent.
> * Will we require that a single outgoing message could be sent via
> multiple protocols? For example, imagine we had facebook integration -
> could a single message be marked as both a tweet and a facebook status
> update?
Yes. Well, no, not required, but would be nice. I could see a feature
where I mark an email as urgent, so it sends a text message to the
receiver that there is an urgent email being sent to them. Or that
could be a feature of the receiving side rather than sending :)
> * Consider a 'sent' item which is also received by an IMAP server (not
> all sent messages will be). Must these 2 versions of the message be the
> same message (ie, must they have the same ID, or can they have different
> IDs, meaning they might appear in searches etc twice?)
I think if it's easy to match them the fine, but avoid getting crazy
trying to match an incoming message with an outgoing message.
James Burke
> The questions:
>
> * General questions about the interaction between local storage and the
> API/back-end - the compose mockups save the drafts to local storage - at
> what point is it expected these will be handed off to the back-end? Does the
> back-end/API need to track these at all, or is it limited to only the
> delivery of the message? IOW, does the back-end need the concept of
> 'draft', or only of 'sent'? If it does need 'draft', how does this interact
> with local storage?
The local storage thing is just a robustness feature -- to prevent
issues with network connectivity, allow "offline" compose. However, it
is my understanding we do want drafts on the server. The local storage
mechanism will reach out to the server to save the draft, but on an
interval that is larger than the local storage save.
> If the backend must track these item, then:
>
> * Do "draft" or "outgoing" items need to be a "real" Message? For example,
> will the /message api be expected to deal with draft message IDs? Will they
> be returned in /conversation API calls or searches? If you ask for items
> "from me", will they appear in the result list?
So IOW, what behaviors should Drafts have? Gmail shows drafts in these
kinds of searches:
- Searching for messages involving me
- Searching for a word that is in a draft
I can see where the display of the draft will not be like a normal
message, and this gets to your question on body_quoted, but I am not
sure exactly how we would show in a text editor the nested quote
structure, and if it should be stored in the backend as just a string
or as a nested body_quoted structure. I would be concerned about loss
of fidelity in the transforms. Maybe it works out, but a good thing to
talk about on the call.
>
> * Must the type of the message be chosen as the draft is created? IOW, must
> the decision about whether a message is an 'email' or a 'tweet' be made
> before the draft is first saved, or can this determination be made later
> (eg, at 'send' time depending on the selected recipients, etc)?
I think this is reasonable to assume (see my next response for more
info). We can always present UI that allows transforming a tweet draft
into a mail draft (which would just delete the tweet draft and create
an email draft using the old tweet draft contents). Also, once you
choose the recipient, I think that will inform the protocol. IOW, I
think any "protocol switching" can be handled in UI, but the BE draft
thing can assume that it will be created with a type.
> * Will we require that a single outgoing message could be sent via multiple
> protocols? For example, imagine we had facebook integration - could a
> single message be marked as both a tweet and a facebook status update?
I vote no -- I believe most people have different cultural
expectations/different social facets based on the protocol, and the
message is likely to be tailored to that protocol (I don't want to
send a friendly NSFW tweet to my contact's work mail for instance). I
also think the UI implications get weird, or at the least clutters the
UI. If it helps simplify the BE design, then let's not do this. If we
become wildly successful later on and people clamor for this feature
we can take the hit then.
> * Consider a 'sent' item which is also received by an IMAP server (not all
> sent messages will be). Must these 2 versions of the message be the same
> message (ie, must they have the same ID, or can they have different IDs,
> meaning they might appear in searches etc twice?)
It seems ideal if we could at least match them up. Perhaps it means
changing the ID of the sent thing to match the one from the service vs
generating an ID we know will come back as the same, which seem hard
to do. Another good topic to talk over.
James