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
Paul Vixie writes:
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
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
14 matches
Mail list logo
