Re: [apps-discuss] Call for Adoption: draft-ordogh-spam-reporting-using-imap

[Ned Freed <[e-mail]>]

> >> (1) The message was classified as spam and the user has not said anything.
> >> (2) The message was classified as spam but the user says it isn't.
> >> (3) The message was not classified as spam and the user has not said
> >>         anything.
> >> (4) The message was not classified as spam but the user says it is.
> >>
> >> You cannot represent all of those in a single bit.
> >
> > Correct, and I think we should /not/ try to represent all those cases.

> I suppose this could be two bits, one the spam state to display, the other
> a less visible flag the user can toggle, but that's not what IMAP does
> with its other flags.

> In all of the webmails I can think of, a message has a displayed spam state,
> either with a visible flag or implicitly because it's in the spam folder.
> When you hit the junk/nojunk button, the state changes immediately.

Exactly. And the problem with that is generating reports either depends on
reporting the transition or comparing the the presented state with an internal
state.

I'm not overly fond of relying on notifications for this sort of thing - it
forces the issue on a number of design choices that have serious impact on high
end servers. That said, we certainly should allow a notification-based approach
to be used, but I see nothing about having the server state available that
prevents that from happening. Indeed, it can be used to provide additional
information, such as when a user disagrees and then changes their  mind. (I
doubt this is useful, but it's always hard to be sure about this stuff.)

> The
> server can certainly remember internally whether the state was generated
> automatically or set by the user, but no webmail I know displays that, so
> I don't see any need to build it into IMAP.

Hidden server state is almost always a bad design choice, especially when
there's essentially no cost involved in exposing it.

Additionally, you're assuming a separation of function across the IMAP boundary
that isn't always how things are implemented.

And finally, what is or isn't *displayed* by current UIs is almost always
a poor thing to design around. Designs need to accomodate the *functionality*
provided by current UIs. 

				Ned