Assuming this is desirable functionality, should I create a ticket in
the posterity trac for this one and/or in the future?
I also made a 'fixdates' command for already-imported messages, but
it's not clear that is desirable to have around since it is arguably
more dangerous.
Andrew
PS: Posterity is awesome. I always hoped something like it existed,
and was pleasantly surprised when I found out it existed a few months
ago.
Cool. Yes this is definitively useful. Would it be possible to add some
kind of detection of obviously incorrect date headers somehow? It might
be enough to detect dates in the future, since that would case messages
to get stuck at the very top of the "All Mail" view.
Another thought: The correct placement for this option should perhaps be
a setting on individual pop3 accounts instead of an option on the
"posterity-admin fetch" command line. This will require a bit more work
and a db schema change.
> Assuming this is desirable functionality, should I create a ticket in
> the posterity trac for this one and/or in the future?
Yes, please do that.
>
> I also made a 'fixdates' command for already-imported messages, but
> it's not clear that is desirable to have around since it is arguably
> more dangerous.
I can see the usefulness of such a command and you're right, it would
probably be a good idea to separate this kind of more dangerous power
user commands from the rest of the posterity-admin command. I can't
really come up with any really good solution for this right now, I need
to think about it some more.
Cheers,
Jonas
All good points/ideas. The future and extreme past seem easy to
contend with. I'm not sure if it's a reasonable assumption, but it
seems like POP3 messages should be chronologically ordered (unless
some form of backfilling occurs), which could then provider even
tighter bounds on the past.
The only time this (tighter bounds) seems like it would be meaningful
is when someone sends a message that is delayed in transit due to a
server being down and a smarthost holding onto it for a few days. In
that case, it seems desirable to not file the message in 'the past',
but rather bump it to 'the present'. That would suggest always taking
the maximum of the 'current time' and the message's time, using that
and setting it to be the 'current time'. I can look into the POP3
spec to make sure this is not completely wrong/a bad idea.
I'll make the proposed changes/enhancements and put it on a trac
ticket. That will probably happen sometime this weekend.
Andrew