* [sup-talk] Minor maildir change
@ 2007-09-09 22:40 Magnus Therning
2007-09-14 3:33 ` William Morgan
0 siblings, 1 reply; 6+ messages in thread
From: Magnus Therning @ 2007-09-09 22:40 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread* [sup-talk] Minor maildir change
2007-09-09 22:40 [sup-talk] Minor maildir change Magnus Therning
@ 2007-09-14 3:33 ` William Morgan
2007-09-16 18:19 ` Magnus Therning
0 siblings, 1 reply; 6+ messages in thread
From: William Morgan @ 2007-09-14 3:33 UTC (permalink / raw)
Excerpts from Magnus Therning's message of Sun Sep 09 15:40:34 -0700 2007:
> 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.
Applied, thanks. #file_path is only used by sup-sync-back so I hadn't
bothered to implemented it.
> 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.
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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [sup-talk] Minor maildir change
2007-09-14 3:33 ` William Morgan
@ 2007-09-16 18:19 ` Magnus Therning
2007-09-19 15:59 ` William Morgan
0 siblings, 1 reply; 6+ messages in thread
From: Magnus Therning @ 2007-09-16 18:19 UTC (permalink / raw)
On Thu, Sep 13, 2007 at 20:33:04 -0700, William Morgan wrote:
>Excerpts from Magnus Therning's message of Sun Sep 09 15:40:34 -0700 2007:
[..]
>> 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.
>
>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.
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
--
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: 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
^ permalink raw reply [flat|nested] 6+ messages in thread* [sup-talk] Minor maildir change
2007-09-16 18:19 ` Magnus Therning
@ 2007-09-19 15:59 ` William Morgan
2007-09-19 22:02 ` Magnus Therning
0 siblings, 1 reply; 6+ messages in thread
From: William Morgan @ 2007-09-19 15:59 UTC (permalink / raw)
Excerpts from Magnus Therning's message of Sun Sep 16 11:19:36 -0700 2007:
> 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.
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.
> - 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.
Not sure what you mean by "actual sets", but I think this is pretty much
the way Sup works now.
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 6+ messages in thread* [sup-talk] Minor maildir change
2007-09-19 15:59 ` William Morgan
@ 2007-09-19 22:02 ` Magnus Therning
2007-09-24 2:29 ` William Morgan
0 siblings, 1 reply; 6+ messages in thread
From: Magnus Therning @ 2007-09-19 22:02 UTC (permalink / raw)
On Wed, Sep 19, 2007 at 08:59:58 -0700, William Morgan wrote:
>Excerpts from Magnus Therning's message of Sun Sep 16 11:19:36 -0700 2007:
>> 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.
>
>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.
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?
>> 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.
Excellent.
[..]
>> - 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.
What I mean is the type set gotten from "require 'set'" :) Currently
labels are lists, not sets.
/M
--
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/20070919/8103ec01/attachment.bin
^ permalink raw reply [flat|nested] 6+ messages in thread* [sup-talk] Minor maildir change
2007-09-19 22:02 ` Magnus Therning
@ 2007-09-24 2:29 ` William Morgan
0 siblings, 0 replies; 6+ messages in thread
From: William Morgan @ 2007-09-24 2:29 UTC (permalink / raw)
Excerpts from Magnus Therning's message of Wed Sep 19 15:02:00 -0700 2007:
> What's gotten from the source is useful for an unseen message, but why
> 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.
> >> - 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.
>
> What I mean is the type set gotten from "require 'set'" :) Currently
> 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. :)
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2007-09-24 2:29 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-09-09 22:40 [sup-talk] Minor maildir change Magnus Therning
2007-09-14 3:33 ` William Morgan
2007-09-16 18:19 ` Magnus Therning
2007-09-19 15:59 ` William Morgan
2007-09-19 22:02 ` Magnus Therning
2007-09-24 2:29 ` William Morgan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox