Subject: [sup-talk] Minor maildir change

From: [email-masked] (Magnus Therning)
Date: Sun, 9 Sep 2007 23:40:34 +0100

I thought it was a little strange the file_path on Maildir objects
returned `nil` so I changed that to return the path of the maildir.

I am somewhat puzzled by the labels one receives from Maildir::each,
it's the default labels for the source rather than the labels of the
actual message.  Especially confusing was the choice to label something
'unread' if it's filename doesn't contains an 'R'.  IIRC 'R' means that
the email has been replied to, it would have been more correct to mark
it unread if it doesn't contain an 'S' (as in seen).  However, it seems
silly to take any of this into consideration when sup doesn't deal with
maildirs "properly" anyway.  I've removed that strangeness, at least
until a full maildir implementation makes it into sup.

/M

=== modified file 'lib/sup/maildir.rb'
--- lib/sup/maildir.rb	2007-09-09 22:27:27 +0000
+++ lib/sup/maildir.rb	2007-09-09 22:29:52 +0000
@@ -27,6 +27,7 @@
     @mutex = Mutex.new
   end
 
+  def file_path; @dir end
   def self.suggest_labels_for path; [] end
 
   def check
@@ -93,7 +94,7 @@
     start.upto(@ids.length - 1) do |i|         
       id = @ids[i]
       self.cur_offset = id
-      yield id, @labels + (@ids_to_fns[id] =~ /,.*R.*$/ ? [] : [:unread])
+      yield id, @labels
     end
   end

-- 
Magnus Therning                             (OpenPGP: 0xAB4DFBA4)
magnus?therning?org             Jabber: magnus?therning?gmail?com
http://therning.org/magnus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://rubyforge.org/pipermail/sup-talk/attachments/20070909/3ea679f1/attachment-0001.bin

---

From: [email-masked] (William Morgan)
Date: Thu, 13 Sep 2007 20:33:04 -0700

> returned `nil` so I changed that to return the path of the maildir.

Applied, thanks. #file_path is only used by sup-sync-back so I hadn't
bothered to implemented it.

> actual message.

It's supposed to be both sets of labels unioned together. The source
defines any user labels the user wants to automatically apply to new
messages (kind of a primitive filtering), and we mix these in with the
labels that carry over the read/unread state, etc.

> Especially confusing was the choice to label something 'unread' if
> it's filename doesn't contains an 'R'.  IIRC 'R' means that the email
> has been replied to, it would have been more correct to mark it unread
> if it doesn't contain an 'S' (as in seen).

Yep, this was a bug.

> However, it seems silly to take any of this into consideration when
> sup doesn't deal with maildirs "properly" anyway.  I've removed that
> strangeness, at least until a full maildir implementation makes it
> into sup.

Hey, as far as Sup is concerned, a source is just a dumb bucket that
occasionally produces a new messages. So in that sense, Maildir is dealt
with "properly". (Sup-sync-back only exists because of the unfortunate
habit of Sup users of wanting to using other email clients alongside
it.) :)

-- 
William <wmorgan-sup at masanjin.net>

---

From: [email-masked] (Magnus Therning)
Date: Sun, 16 Sep 2007 19:19:36 +0100

>Excerpts from Magnus Therning's message of Sun Sep 09 15:40:34 -0700 2007:
[..]
>labels that carry over the read/unread state, etc.

This is still confusing to me.

It's also a little strange that after a message is read it doesn't
necessarily end up with the correct set of labels.  Instead one has to
go to the index to get the proper set.

Another strange thing was that when using PollManager::add_messages_from
all my emails ended up being unread (according to the labels in the
message).  I tracked that down to it using the value of a header
("Status") to see whether a mail was read or not.  Is that something
that's used for mboxes?  (I've attached a patch that removes the code.)

This adds up to some smelliness IMHO.  I've done some thinking and I
think I'd like something like this:

 - A source has some default labels (including :archive).

 - A message is always loaded from a source so it'll get its labels from
   the source iff it's a new message.  If it's a known message it'll
   take its labels from the database.

 - Make all sets of labels actual sets.

Would this fit with the way the rest of sup works?

/M

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sup-lblfix.diff
Type: text/x-diff
Size: 561 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/sup-talk/attachments/20070916/6f2933e7/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://rubyforge.org/pipermail/sup-talk/attachments/20070916/6f2933e7/attachment-0001.bin

---

From: [email-masked] (William Morgan)
Date: Wed, 19 Sep 2007 08:59:58 -0700

> go to the index to get the proper set.

What do you mean? For a new, unseen message, the initial set of label is
uniquely determined by the source's default labels, unioned with
whatever state (read/unread, flagged, etc) we carry over from the
source. This is what Source#each does.

Now sup-sync has some complicated behavior that does involve the labels
on the index, but that has to do with situations where the message
already exists in the index, or the message state exists in a dumpfile
somewhere, and you're resolving the two potentially different label
sets.

> Another strange thing was that when using
> PollManager::add_messages_from all my emails ended up being unread
> (according to the labels in the message).  I tracked that down to it
> using the value of a header ("Status") to see whether a mail was read
> or not.  Is that something that's used for mboxes?  (I've attached a
> patch that removes the code.)

That is a hack to avoid having the mbox code read the header twice, one
for the labels and again for the actual header contents.  Since I'm
planning on reworking mbox anyways (to avoid keeping the file pointer
always open, and to clean up the interface between loader and
ssh-loader), so I'll try and think of a better way to do this. There
might not be.

In the mean time, I'll remove the second half of that statement, which
should make everyone happy.

>  - Make all sets of labels actual sets.

Not sure what you mean by "actual sets", but I think this is pretty much
the way Sup works now.

---

From: [email-masked] (Magnus Therning)
Date: Wed, 19 Sep 2007 23:02:00 +0100

On Wed, Sep 19, 2007 at 08:59:58 -0700, William Morgan wrote:
>What do you mean? For a new, unseen message, the initial set of label
>is uniquely determined by the source's default labels, unioned with

Yes, but once it's known Source#each still get labels off the state and
default flags from the source.  The same goes for
PollManager#add_messages_from, where the messages will have different
labels compared to the entry.  Here's code that hopefully highlight
what I mean:

  #!/usr/bin/env ruby
  
  require "uri"
  require "sup"
  
  Redwood::start
  index = Redwood::Index.new
  index.load
  
  index.sources.each { |src|
      if "maildir" == URI(src.uri).scheme
          src.reset!
  
          Redwood::PollManager.add_messages_from(src) { |m, offset, entry|
              puts "#{offset} -"
              puts "\t#{m.labels.join(' ')}"
              puts "\t#{entry[:label]}"
              nil
          }
      end
  }

The output on a maildir source I use for some testing is:

  [Wed Sep 19 22:55:02 +0100 2007] loading index...
  [Wed Sep 19 22:55:02 +0100 2007] loaded index of 3 messages
  11755314090094973 -
          sup-test unread deleted inbox
          sup-test
  11765622040003515 -
          sup-test unread inbox
          sup-test deleted
  11776152050016455 -
          sup-test inbox unread
          sup-test unread

What's gotten from the source is useful for an unseen message, but why
not mark known messages with the labels from the index?

>should make everyone happy.

Excellent.

[..]
>Not sure what you mean by "actual sets", but I think this is pretty
>much the way Sup works now.

What I mean is the type set gotten from "require 'set'" :)  Currently
labels are lists, not sets.

/M

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://rubyforge.org/pipermail/sup-talk/attachments/20070919/8103ec01/attachment.bin

---

From: [email-masked] (William Morgan)
Date: Sun, 23 Sep 2007 19:29:35 -0700

> not mark known messages with the labels from the index?

If your question is, why does Source#add_messages_from yield what it
does, the answer is because all consumers either need the source labels
(for polling) or need both (for syncing---check out sup-sync for the
gory details). Thread-view-mode and all its decendents (inbox-mode, etc)
all talk directly to the index and don't use that method at all.

> labels are lists, not sets.

Honestly, I don't see a real advantage to retrofitting that class onto
things. It doesn't appeal to my Ruby instincts. :)