body_quoted
Mark Hammond
"body_quoted" format for outgoing messages. The use of body_quoted
makes sense as (a) often you will be replying to a message, and the FE
already uses this format for the message you are replying to and (b) it
means the front-end can leave the line wrapping and quote marking
semantics to the back-end.
However, I think the the body_quoted field is currently "under
specified" and now is probably a reasonable time to tighten it up. In
particular, I think we need:
* Support for "flowed" text - that if the email is "format=flowed", the
back-end removes all "soft" line breaks breaks. IOW, when possible,
multiple lines in the same paragraph should be rolled into a single
line. The front-end (via the browser) can then wrap it as an entire
paragraph. This is likely to be particularly true for mobile clients
where 80-character lines are unlikely to always fit without horizontal
scrolling.
* Better quoting support. Assuming the above "flowed" semantics, a
single quote block may be collapsed into a single line/paragraph. This
probably means the leading ">" character will not offer as many clues as
it does now about the quoting. This implies to me that the leading ">"
chars should be removed and be replaced with an explicit "quote depth"
integer and the FE can use styling tricks to indicate the quoting and
the depth.
But the devil is in the detail :) I had a quick go at that, but the way
the front-end implements the "show/hide quote" button means that it
assumes all quotes in one block, regardless of depth, are in the same
"quote" section.
I feel the ability for correct quoting will become important as soon as
we try and use raindrop for real, but probably need some help in
thrashing out a good compromise between capturing the full quoting
semantics we will need and allowing the front-end to stay simple.
Any thoughts?
Mark
James Burke
> For outgoing messages, it makes sense (to me) that we reuse the
> "body_quoted" format for outgoing messages. The use of body_quoted makes
> sense as (a) often you will be replying to a message, and the FE already
> uses this format for the message you are replying to and (b) it means the
> front-end can leave the line wrapping and quote marking semantics to the
> back-end.
>
> However, I think the the body_quoted field is currently "under specified"
> and now is probably a reasonable time to tighten it up. In particular, I
> think we need:
>
> * Support for "flowed" text - that if the email is "format=flowed", the
> back-end removes all "soft" line breaks breaks. IOW, when possible,
> multiple lines in the same paragraph should be rolled into a single line.
> The front-end (via the browser) can then wrap it as an entire paragraph.
> This is likely to be particularly true for mobile clients where
> 80-character lines are unlikely to always fit without horizontal scrolling.
Just to make sure: this sounds like something the backend would only
care about, the FE would not explicitly look at the format=flowed
property on the body_quoted section.
> * Better quoting support. Assuming the above "flowed" semantics, a single
> quote block may be collapsed into a single line/paragraph. This probably
> means the leading ">" character will not offer as many clues as it does now
> about the quoting. This implies to me that the leading ">" chars should be
> removed and be replaced with an explicit "quote depth" integer and the FE
> can use styling tricks to indicate the quoting and the depth.
I'm not sure I exactly understand, but instead of a quote depth
integer, what about just nesting quoted body structures?
James
Mark Hammond
> Just to make sure: this sounds like something the backend would only
> care about, the FE would not explicitly look at the format=flowed
> property on the body_quoted section.
That's correct. If the back-end saw format=flowed, you would just end
up with very long "lines" in each section (indeed, each "line" is really
then a paragraph). If format=flowed was *not* found, you just end up
with lots of short lines.
It might be nice to include another attribute to indicate if this
unwrapping took place, but I don't think it is necessary.
>> * Better quoting support. Assuming the above "flowed" semantics, a single
>> quote block may be collapsed into a single line/paragraph. This probably
>> means the leading ">" character will not offer as many clues as it does now
>> about the quoting. This implies to me that the leading ">" chars should be
>> removed and be replaced with an explicit "quote depth" integer and the FE
>> can use styling tricks to indicate the quoting and the depth.
>
> I'm not sure I exactly understand, but instead of a quote depth
> integer, what about just nesting quoted body structures?
Yeah, that would work too and I didn't express myself very well. The 2
options I see are:
* Stick with a 'flat' structure but indicate the depth with an explicit
integer.
* Use a nested structure where the depth is implied.
Both of these are representing a "tree" structure, but in different
ways. A nested structure more naturally represents this and makes it
easier to perform "nested" hide/show quotes, which is probably what we
need to end up with anyway.
I guess the questions really are:
* Would moving to nested structure place an undue burden on the front end.
* If not, what should such a structure look like (ie, what nested
structure would be optimal for the FE)?
Cheers,
Mark
Mark Hammond
body_quoted:
* A "message chunk" is defined as a list of json objects. Each object
has a 'type' field and a 'value' field.
* For objects with a type='text, the value is a simple string.
* For objects with a type='quote', the value is itself a list of
"message chunk" objects.
* The body_quoted field is itself a "message chunk" object.
As you can see, the definition is recursive. The idea is that each
'quote' is in exactly the same format as body_quoted itself. This makes
creating a new body_quoted for replying fairly trivial - ie, something like:
: reply_body_quoted = [{type: 'quote', value: msg.body_quoted}]
Would give you back a new body_quoted structure with everything now
being one quote-level deeper.
Does this make sense? I've included some examples below...
Mark
Examples:
The message:
"""
hello there!
Someone writes:
> this is one para of quoted text
> this is the 2nd para of quoted text
>> this is requoted text
"""
would result in:
body_quoted = [
{type='text', value='hello there!'}
{type='text', value='Someone writes:'}
{type='quote', value=[
{type='text', value='this is one para of quoted text'},
{type='text', value='this is the 2nd para of quoted text'},
{type='quote', value=[
{type='text', value='this is re-quoted text'},
]},
]},
]
The message:
"""
This is strange
>> re-quoted line
> this is one para of quoted text
>> another re-quoted
"""
would result in:
body_quoted = [
{type='text', value='this is strange"'}
{type='quote', value=[
{type='quote', value=[
{type='text', value='re-quoted line'},
]},
{type='text', value='this is one para of quoted text'},
{type='quote', value=[
{type='text', value='another re-quoted'},
]},
]}
]
An edge case:
"""
>> re-quoted line
what the?
"""
results in:
body_quoted = [
{type='quote', value=[
{type='quote', value=[
{type='text', value='re-quoted line'},
]}
]},
{type='text', value='what the?'}
]
James Burke
<mham...@skippinet.com.au> wrote:
> Does this make sense? I've included some examples below...
I meant to respond sooner, but this makes sense to me. Nice examples too!
James