Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement drafts for all sources #320

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

rakoo
Copy link

@rakoo rakoo commented Jul 26, 2014

We just have to provide the relevant filename for the message to edit,
and then remove the :draft label from the message when all is done.

To test:

  • Add a draft in your remote server
  • Sync to local index
  • Edit draft

Should solve #220

We just have to provide the relevant filename for the message to edit,
and then remove the :draft label from the message when all is done.
@gauteh
Copy link
Member

gauteh commented Jul 28, 2014

Doesn't this leave old drafts in the sup://drafts source? Are not drafts left around in other sources (should they not be deleted in the maildir when it has been sent)?

@rakoo
Copy link
Author

rakoo commented Jul 28, 2014

Doesn't this leave old drafts in the sup://drafts source?

All drafts in sup://drafts would remain there, and new draft will be written in sup://drafts too. But to me the idea of indexing messages and accessing them through the labels means that by removing the :draft label they won't be visible as such. So they will physically be there but logically will not.

If you mean that messages should gradually be "garbage-collected", yes, that's a possibility (I believe user wouldn't want to see a pile of useless junk)

Are not drafts left around in other sources (should they not be deleted in the maildir when it has been sent)?

Again, to me sources are just raw data inputs, and the truth about states is in the sup index. If this index says that the message is not a draft anymore, it is enough for us to treat the message accordingly.

In the case of a sync back then the correct measures are taken.

Now, something that can create problems is if the same content is present with two different message ids, one for the real message sent, one for the ex-draft. I guess what we want to do here is when we remove :draft in Message.remove_label and there are no other user-settable labels, we remove the message from the index ?

@gauteh
Copy link
Member

gauteh commented Jul 28, 2014

a) garbage collection / deletion from sup://drafts

This at least has been the behaviour before. For me it seems to be the most logical as well, if I create a draft in sup and later discard it or send it (in which case a copy will be stored in sup://sent) I would also want the physical copy to be removed - otherwise there would exist a useless duplicate. So yes, I guess I mean they should be garbage collected continuously.

b) remnants of drafts in maildir-sources

Perhaps we can make the distinction between removing the :draft label and discarding a draft. If we would like to utilize draft messages in a maildir source, and being able to set the draft source (sup://drafts) to an arbitary source, I think an identical behaviour is logical: discarding a draft also deletes the physical copy, sending a draft stores a copy in sent and deletes the draft. The ability to remove or add the :draft label to any message could be discussed, will this be a real use case?

In the case of discarding drafts: I think the current File.delete should be replaced by a call to a source method that deletes the message, probably going through through the index. I think the behaviour should stay the same, at least for conventional sup://drafts - where the message is deleted from disk on draft discarding.

I've been missing the ability to keep drafts in maildirs with sync back (so to keep this synced between clients), it would be great to have that!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants