On 2012-06-26 06:30, Paul Vixie wrote:
On 2012-06-26 3:19 AM, Jerrad Pierce wrote:
Sorry for the premature reply.
I see now that Paul did understand my idea.
I can underatd that some might not want duplicate
content, but that's what I proposed it be optional.
A temporary cache does not
Paul Vixie p...@redbarn.org writes:
i consider MH's basic mailbox format to be flawed in a MIME world for
which MH was never designed or redesigned. every attachment should be in
its own file, even if that meant that messages were directories no
longer files themselves.
note, i know we
On 2012-06-26 11:45 AM, Paul Fox wrote:
anyway: i think i still prefer the idea that the content cache
directories be kept in the message tree. but i also understand why
one might want them separate. if the idea is that the message tree
and the cache tree are roughly isomorphic, i'll bet
as an unfortunate and unnecessary burden on code whose assumptions have
been valid for a long time.
But it's still an assumption, and we know what those mean.
More seriously though, is there an actual spec for MH declaring
what valid folder and filenames are?
What's the worst-case for those using
paul wrote:
On 2012-06-26 11:45 AM, Paul Fox wrote:
anyway: i think i still prefer the idea that the content cache
directories be kept in the message tree. but i also understand why
one might want them separate. if the idea is that the message tree
and the cache tree are roughly
On 2012-06-26 3:02 AM, Ken Hornstein wrote:
int m_getfld (int state, unsigned char *name, unsigned char *buf, int
bufsz, FILE *iob)
Okay ... just shooting from the hip, and based on our discussion back
in January ... here's something (I'm ignoring how this would be
implemented for now, and
A few points on this discussion:
1) The person who promised to re-write the API was an Internet Elder.
Google it.
2) Callbacks vs data structures
One reason you might want to have callbacks is that the content might be
GPG or otherwise encrypted and you may want to prompt the user. You
On 2012-06-26 11:18 PM, Jeffrey Honig wrote:
A few points on this discussion:
1) The person who promised to re-write the API was an Internet Elder.
Google it.
and after that... bite me.
2) Callbacks vs data structures
One reason you might want to have callbacks is that the content
Paul Fox wrote:
why couldn't an indexer know the difference between the message file
and the content cache?
anyway: i think i still prefer the idea that the content cache
directories be kept in the message tree. but i also understand why
one might want them separate. if the idea is that
Paul Vixie writes:
On 6/25/2012 10:43 PM, Tethys wrote:
Ken Hornstein writes:
A possible way to solve the access to MIME parts problem
might be to store the parts as messageNumber.partNumber*
Creation of these parts would be optional, and eat space,
but it would make indexing/grepping
You know ... given that Norm's comments, that actually might work.
Thoughts?
i'm opposed. what should be in the file system is what SMTP received and
handed to /var/mail or whatever.
My personal thoughts in terms of implementation was that 53 would be
the original message. 53.mime would
On 2012-06-25 11:56 PM, Ken Hornstein wrote:
I also note that thread included someone (who shall remain nameless)
offering to design a new API to replace m_getfld() :-)
let's start talking about what it should look like?
___
Nmh-workers mailing list
Paul Vixie writes:
On 2012-06-25 11:56 PM, Ken Hornstein wrote:
I also note that thread included someone (who shall remain nameless)
offering to design a new API to replace m_getfld() :-)
let's start talking about what it should look like?
Well, for starters, it shouldn't include any
On 2012-06-26 2:28 AM, Jon Steinhart wrote:
Paul Vixie writes:
let's start talking about what it should look like?
Well, for starters, it shouldn't include any threatening commmentary!
Big thing that I think that it needs other than cleanup is the ability
to scan for attachment part headers
Vixie Re: [Nmh-workers] mime-aware filtering?On
1695.1 image/png name=foo
1695.2 application/pdf
It would be nice to be able to decode the body parts to flesh out the part
subject lines but even without that it would be a huge improvement.
I
hindsight, but one of them was to extend the definition of headers. So,
I'm proposing that m_getfld be extended so that it finds these extended
headers.
I think Paul made his convincing case here that m_getfld() needs to die:
http://lists.gnu.org/archive/html/nmh-workers/2012-01/msg00248.html
You seem to have misunderstood my proposql.
Paul, Message 76 would still be what came over the wire,
however something like mhstore could optionally make 76.*
as the split out compoents
Tet, nothing in what I wrote implied you couldn't have
76.1.1.4 grep's, not going to care.
m_getfld() is the heart of MH.
Truer words have never been spoken; it's used by so much (including the
profile parser).
so when i say let's talk about what m_getfld should look like i really
mean let's talk about what MH's storage and access model should be.
int
m_getfld (int state, unsigned
Paul Vixie wrote:
mhpart (or whatever) would need a -clean option to get rid
of the /var/tmp files it has made for you in this session.
but i do not think we should pollute the Mail subdirectory
hierarchy with permanent copies of parts.
nmh already has nmh-cache, how about putting parts
On 2012-06-26 3:01 AM, Jerrad Pierce wrote:
You seem to have misunderstood my proposql.
Paul, Message 76 would still be what came over the wire,
however something like mhstore could optionally make 76.*
as the split out compoents
Tet, nothing in what I wrote implied you couldn't have
Sorry for the premature reply.
I see now that Paul did understand my idea.
I can underatd that some might not want duplicate
content, but that's what I proposed it be optional.
A temporary cache does not allow for indexing.
Keeping it in Mail means you have whichever
decoded messages you want
at a high level, how do people feel about callbacks vs. state blobs?
that is, would we like the replacement for m_getfld() to continue to
return each time it finds something, maintaining its state in a
caller-supplied opaque state blob, or would we like it to call the
caller's work function every
On 2012-06-26 3:19 AM, Jerrad Pierce wrote:
Sorry for the premature reply.
I see now that Paul did understand my idea.
I can underatd that some might not want duplicate
content, but that's what I proposed it be optional.
A temporary cache does not allow for indexing.
i'm ok with that. disk
ken wrote:
nmh tools ignore non-numeric filenames, doesn't it?
To answer that question more specifically ... it will ignore any filename
that fails m_atoi(), which will reject anything that contains something
that is !isdigit().
A possible way to solve the access to MIME parts
nmh tools ignore non-numeric filenames, doesn't it?
To answer that question more specifically ... it will ignore any filename
that fails m_atoi(), which will reject anything that contains something
that is !isdigit().
A possible way to solve the access to MIME parts problem
might be to store the
i realized yesterday that the ever-increasing base64-ization of mail
is starting to break my procmail filters, some of which look into the
body of the message. i'd welcome any excuse to switch to something
other than procmail, so: are there any mime-aware filtering programs
out there? slocal
but i might have missed something. the sieve specification seems like
it could do it, but all the implementations seem to be imap-centric,
and live on the server. again, maybe i missed something.
I think you're right in that slocal probably isn't worth extending to do
what you want. So to keep
Paul wrote:
i realized yesterday that the ever-increasing
base64-ization of mail is starting to break my procmail
filters, some of which look into the body of the message.
I've been feeling a need for that recently, too. While I
wouldn't mind moving away from procmail, this is its only
On 6/22/2012 7:53 PM, David Levine wrote:
Paul wrote:
i realized yesterday that the ever-increasing
base64-ization of mail is starting to break my procmail
filters, some of which look into the body of the message.
whoa. blast from the past.
I've been feeling a need for that recently, too.
29 matches
Mail list logo
